[webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]

Darin Fisher darin at chromium.org
Mon Nov 30 21:07:11 PST 2009

On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt <oliver at apple.com> wrote:

> On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote:
> On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote:
>> Following up, I think this highlights the distinct set of use cases that
>> shared workers and shared script address:
>> SharedWorkers are a great platform for when you have a single database
>> that is shared across multiple instances of your web app, and you want to
>> coordinate updates to that database. I can imagine sharing a single
>> connection to the server, etc via SharedWorkers.
>> SharedScripts are a good platform for when you want to share data/code
>> (for example, the immense body of Javascript used to implement the Gmail UI)
>> across multiple windows. I can't speak to whether passing a hidden iframe
>> between windows as was suggested in the other thread would address this use
>> case sufficiently.
>> Would it be fair to say the goal for SharedScript is just to share code
>> and data (to reduce memory use of multiple instances of GMail), and not
>> network connections, timers, or other APIs based on async callbacks
>> (assuming those either remain per-Window or are in the SharedWorker)? If so,
>> then it would pretty much completely be handled by sharing of some arbitrary
>> JavaScript object, possibly arranged by SharedWorker.
>> Sharing an out-of-document HTMLIFrameElement would almost even account for
>> timers and the like, except that currently in WebKit a frame's Window does
>> not exist and its contents are not loaded if the frame is not rendered.
> XHRs also don't work after the frame has been unloaded.
> I think my primary concern is that the use of _Shared_ or _Global_ in the
> name implies behaviour similar to that of SharedWorker, which is not
> guaranteed, likewise origin based object lifetime can trivially result in
> differences in behaviour between browser (which when coupled with the naming
> issue) could easily become a headache for developers.
> It seems that what is really wanted is a Worker context that isn't actually
> a separate thread, so avoiding the need for postMessage, and have it be
> explicitly instantiated so as to avoid any browser-architecture derived
> behavioural differences. eg.
> var mySharedContext = new SharableScriptContext("script to load here?");
> mySharedContext.onload = function() {
>     doStuff();
> }
> // or should it be
> // mySharedContext.src = "script to load here?"
> Later on:
> function doSomethingCoolThatNeedsANewWindow() {
>     var win = window.open(...);
>     win.onload = function() {
>         win.functionThatTakesScriptContext(mySharedContext);
>     }
> }
> // Note handling the passing of the shared context is entirely developer
> defined -- eg. the only spec behaviour is the 'new SharableScriptContext'
> everything else is whatever the developers wants
> // Note 2: I am truly awful at naming things so these names are mostly
> chosen to clarify unambiguously-ish what i believe the goal is
> The downside is that it requires manually passing the context to new
> windows, the plus side is that it doesn't provide (or imply) behaviour that
> may be ('necessarily') different between UAs.
> --Oliver

This seems pretty compelling to me.

I think if we also had a function like window.getWindowByName(name), then we
could support the use case of a newly opened window connecting to an
existing window to get access to an existing SharableScriptContext.

(To further support sharing from a newly opened window, perhaps it would be
interesting if application manifests could be leveraged to identify URLs
that should be loaded in the same browsing context.)

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

More information about the webkit-dev mailing list