[webkit-dev] GlobalScript in WebKit
mjs at apple.com
Mon Nov 30 17:56:45 PST 2009
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>
> 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
> elect a leader Window within each same-process group, which could
> The object does not get GC'd until all the referencing windows go
> 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
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
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...
More information about the webkit-dev