[webkit-dev] GlobalScript in WebKit
Darin Fisher
darin at chromium.org
Mon Nov 30 20:31:28 PST 2009
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.
-Darin
>
> - Maciej
>
>
> -atw
>
> On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson <atwilson at google.com> wrote:
>
>> I believe that the offline gmail team uses the Gears flavor of shared
>> workers and is planning to migrate to the HTML5 version once DB access is
>> supported from within worker context in shipping browsers.
>>
>> So I guess that Gmail would be a candidate app that has asked for both.
>>
>> -atw
>>
>>
>> On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>>
>>> On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:
>>>
>>> I don't think it's correct to say that SharedWorkers are not useful and
>>>> "we need a SharedScript instead". They are different things and can address
>>>> different use cases. For example, SharedWorker is great to make sure there
>>>> is only one 'app instance' running - exactly because it is shared
>>>> inter-process, it can be used as a "inter-process synchronization primitive"
>>>> to control how many app instances are opened. SharedScript is a container
>>>> for data and code shared between pages that comprise a "web application" and
>>>> normally run in the same process. As in native apps, whether or not multiple
>>>> instances of the app can run at the same time depends on the author of the
>>>> app, and can be done either way.
>>>>
>>>
>>> Are there any Web apps at Google or elsewhere currently using
>>> SharedWorker? Would any of them still use it if they could switch to
>>> SharedScript? Has any app team specifically requested support for *both*
>>> SharedWorker *and* SharedScript? (Serious questions, since the justification
>>> for SharedScript is largely based on Web developer feedback.)
>>>
>>> Note: if SharedScript was really globally shared it could be used to
>>> implement shared workers - simply have the SharedScript manage the per-app
>>> Workers.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>>> _______________________________________________
>>> 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/20091130/ba9dc8a4/attachment.html>
More information about the webkit-dev
mailing list