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

[Darin Fisher]

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.)

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