On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak <m...@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. 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. Dmitry
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev