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

Tue Dec 1 10:05:09 PST 2009

On Tue, Dec 1, 2009 at 12:11 AM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Nov 30, 2009, at 11:47 PM, Adam de Boor wrote:
>
> A worker context without the thread is close to what we're after, except
> for the bit about how it doesn't do network stuff or timeouts.
>
>
> Errr, what?  Workers can do networking, timeouts -- xhr, setTimeout,
> setInterval, etc is available to them so i'm not sure what you mean by that?
>

I was referring back to an earlier message from Maciej:  "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)?"

> As for the DOM -- the only reason for a Worker not having access to the DOM
> is because the only means for communication is postMessage which doesn't
> allow pass by reference (and most/all DOM implementations assume single
> threaded access).  Assuming this magical object existed you would be better
> off thinking of it as being an iframe without a document and with a lifetime
> unbounded by its parent.
>

This magical object is what SharedScript is speced to be.

>
> Fundamentally what we need is, a place for centralizing network access and
> significant amounts of application state, and sharing large amounts of code,
> that is independent of any single window, and can manipulate the DOM of an
> arbitrary number of application windows that are either created by code in
> this independent context, or created by the user through navigation. We'd
> like to be able to create this context from an extension, so if a user
> wishes to have instant access to their gmail, or facebook, or whatever, they
> could choose to install an extension that would create this context when the
> browser starts.
>
>
> I'm not sure how this would work -- as far as I am aware extensions in
> chrome make use of isolated worlds, which should prevent an extension from
> creating an object that can be shared with any normal webpage, and of course
> the extension would not be in the same origin as the page you're hoping for
> so wouldn't be able to share anything anyway.
>

This would be an addition to extensions.

> That said your whole extension for preloading concept seems like it could
> be mostly duplicated by using the application cache -- you'd still get hit
> with compilation time (theoretically once in this model) but compared with
> load time compilation is inconsequential.
>

The application cache as specified is simply a way of storing resources as a
unit, with background update. One could leverage it to store other things
about the application (e.g. freeze-drying the app most of the way through
startup so it can be started again faster), but it's got nothing to do with
having the application headless-but-alive, with data downloaded from the
server, able to generate notifications, if the user has requested them, etc.

>
>
> Shared workers fundamentally don't do the trick because (a) most of the
> code in the application has nothing to do with accessing the server, and
> everything to do with presenting the UI, so shared workers don't help with
> sharing the code among multiple windows, and (b) we want the UI to be
> immediately responsive, which means not waiting for a worker thread to get
> back to the UI thread with data, so we'd be caching the data both in the UI
> context and in the worker thread context, in which case we might as well
> just go to the server.
>
> Errr, if asking a worker for data is taking as long as a server request
> there's a bug...  I'm really not sure what you're saying here.
>

It's less a question of speed than it is of control flow. What's the
advantage of requiring applications to structure themselves so that all
accesses to data are asynchronous? If you look at applications that access a
database, for example, they will frequently make local caches of read-only
data, but they don't then put those caches in another thread that requires
them to break their event handling into stages. What would be the point?
Given that there's no burden on the app in sending a request to the server
(the browser effectively does it in the background), there's no reason to
put it in a worker thread.

a

>
>
> When using a named window, there are interesting race conditions (unless
> you do something like the appcache suggestion to ensure the windows are in
> the same process) when one is restoring the browser state on startup. The
> significant challenge for the app developer is to deal with, when the named
> window closes, in-flight non-idempotent XHRs and registered timeouts that
> ought to be independent of any window, but that are tied to the named
> window. Timeouts are easier to deal with (centralized timer manager that
> remembers the deadline for each and reschedules in the context of the new
> named window). Being able to reparent an XHR in flight would make handling
> the transition easier....
>
>
> From what you're saying here it sounds like you're assuming the
> SharedScript/GlobalScript concept would be guaranteed to be unique in all
> normal (eg. single browser) cases (so in chromium potentially across
> multiple processes), yet chromium developers have repeatedly stated that
> they would not be shared across multiple processes.
>
> --Oliver
>
>
> a
>
>
> On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>>
>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/20091201/37d5d6ec/attachment.html>