On Mon, Nov 30, 2009 at 5:37 PM, Dmitry Titov <dim...@chromium.org> wrote:
> 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. > With the exception of timers, most of these things would also suffer from network errors. I wonder if the same code could be used to recover from them. In addition, everything you mentioned would be a good use case for a SharedWorker since it'd be fairly detached from UI and is async. > 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. >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev