[webkit-dev] GlobalScript in WebKit

[Jeremy Orlow]

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

I believe this is one of the main points we're not all agreeing about (even
within Google).

I believe Dave Levin and Michael Davidson are saying that network
connections, timers, etc would be useful within a global context that's not
shared among multiple pages (like SharedScript).  I've argued that it's not
that big of a leap to do storage and network access from a shared worker
since it's async anyway, but I've never worked on a web app of GMail's
scope....

But even if you subscribe to the idea that network connections, storage, etc
should be done in shared workers because they're async anyway, it seems as
though there might be use cases for timers being shared between pages since
they often drive things that are directly related to the UI.  A (weak)
example would be blinking chat windows that are on multiple pages.

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