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

[Darin Fisher]

On Mon, Nov 30, 2009 at 10:12 PM, Dmitry Titov <dimich at google.com> 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);
>

actually, you'd use this like so:

var mySharedScriptContext;
var win = window.getWindowByName("foo"); // does not create a window if
there is no "foo", searches in same process
if (win)
  mySharedScriptContext = win.functionThatReturnsSharedScriptContext();
if (!mySharedScriptContext) {
  mySharedScriptContext = new SharedScriptContext("foo.js");
  ...
}

In other words, getWindowByName becomes a tool that you can use to locate
existing windows in your application so that you can get access to the
already constructed shared script context.



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

Yes.

-Darin



>
> 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/cef7a707/attachment.html>