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

[Oliver Hunt]

On Nov 30, 2009, at 10:12 PM, Dmitry Titov wrote:

> At first look, this would solve same use cases as SharedScript. The difference is that it has to be passed to participating windows explicitly. Summing up, just for reference:
> 
> var mySharedScriptContext = new SharedScriptContext("foo.js");
> mySharedScriptContext.onload = ...;
> 
> later:
> var win = window.open(...);
> win.functionThatTakesSharedScriptContext(mySharedScriptContext);
> 
> alternatively, later:
> var win = window.getWindowByName("foo"); // does not create a window if there is no "foo", searches in same process
> if (win)
>    win.functionThatTakesSharedScriptContext(mySharedScriptContext);
> 
> and, possibly: add a list (regexp?) to App Cache manifest to describe the set of URLs loaded into the same process to make them able to find each other without relying on window.open().
The idea behind SharedScriptContext+getWindowByName was that it would be possible to do (in your new window)
if (sharedWin = getWindowByName("OriginWindow"))
    sharedContext = sharedWin.sharedContext;
else {
   name = "OriginWindow";
   sharedContext = new SharedScriptContext("foo.js");
}

At least that was my understanding.

What is your application cache suggestion attempting to do?  The whole point of getWindowByName is that it doesn't need window.open

All that said, Darin, Maciej and I were discussing this on IRC earlier and it would seem that simply adding getWindowByName (or some such) would gain a very large amount of the behaviour desired in the {Shared, Global}Script[Context] concept.

--Oliver

> 
> Dmitry
> 
> On Mon, Nov 30, 2009 at 9:07 PM, Darin Fisher <darin at chromium.org> wrote:
> 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
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 

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