[webkit-dev] GlobalScript in WebKit

[Maciej Stachowiak]

On Nov 30, 2009, at 5:37 PM, Dmitry Titov wrote:

> On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> By the way, we could enable the SharedScript programming model at  
> much lower WebKit-level implementation cost and with much less API  
> surface as follows:
>
> - Allow Window to be passed via the structured clone algorithm over  
> a MessageChannel, but it throws on all access if the recipient is  
> not same-origin, in the same thread, and eligible for synchronous  
> calls (i.e. in the same process).
>
> I believe this would allow SharedScript to be implemented in  
> JavaScript. Essentially you'd use a SharedWorker to coordinate and  
> elect a leader Window within each same-process group, which could  
> then create a JavaScript object which it vends to all other Windows.  
> The object does not get GC'd until all the referencing windows go  
> away.
>
> Yep, a variants of this were proposed... One difficulty with this is  
> that while JS object is kept alive, the interesting objects like  
> timers, XHR, WebSockets die once leader Window is closed.

These could all be proxied to a SharedWorker (with callbacks possibly  
delivered to the current leader window). This would involve some extra  
cross-thread messaging overhead but would not require restarting when  
the leader Window is closed. Alternately, JS-level wrappers could be  
made in which handle changes in the leader window transparently.

> Plus, the leader [re]election algorithm should be implemented. It is  
> not impossible to keep track of enough things to fix up the context,  
> but it is way too difficult and error-prone.
>
> It sounds like by making it easier with SharedScript we'd remove the  
> burden of those implementations from many web developers. Just  
> connect to it and it provides stable JS context for things to run in.
>
> If we go with this, I believe we'll need to follow up with things  
> like making XHR work even if page created it was closed... It might  
> end up being essentially the same as SharedScript itself.

I agree that SharedScript would make things easier on content authors  
compared to my proposal, in particular, it would save the effort to  
implement a SharedScript-like environment via a JavaScript library.  
But for experimental features, prototyping mostly or entirely in JS is  
a lower-risk approach, since it allows issues to be discovered without  
risking premature lockin of a feature that doesn't work out. You can  
even try multiple different approaches at once via different JS  
libraries.

Regards,
Maciej

P.S. I haven't seen an answer to Hyatt's question about whether  
SharedScript is intended as a purely experimental feature that doesn't  
ship enabled in release versions or if it's intended to ship in product.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/a2c885bb/attachment.html>