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