[webkit-dev] GlobalScript in WebKit

[Michael Davidson]

Hi folks -

I'm one of the Gmail engineers who worked on the SharedScript proposal. I
thought I'd jump in and give my perspective as a developer.

The thread has gotten a little broad, so apologies if I miss something. It
seems to me there are a few separate questions being discussed:

1) In isolation, is SharedScript a good idea?

People seem neutral-to-positive, so I won't spend time addressing this. It's
clearly something that would be useful. There are open questions about how
it works with Chrome's process model, but I think that's mostly just
implementation details. In a world where SharedWorkers never existed, I
think people would be jumping on this.

2) Given that WebKit has committed to supporting SharedWorkers, is
SharedScript a good idea?

I think so. Background processing and sharing are orthogonal. It seems odd
to me to require the former to get the latter.

The problems that Drew pointed out upthread are real. Putting UI code in a
SharedWorker is not feasible. Web apps are event driven. The user does
something, the app responds by looking at its data and updating the UI.
Introducing an async seam in between those operations is extremely
difficult. I'm unaware of a UI framework that forces that programming model
on developers. (I believe that Cocoa is the same - one UI thread that pumps
messages, and new threads are only spawned at the developer's request. All
we want is to have multiple windows that can work like that!) It's not that
the cost of migrating Gmail to such a model would be high (although it
would). The amount of code that we have that deals with the UI and needs to
look at our shared state is huge. Sharing that code *and* the data model
across windows would be a big win for Gmail latency.

I sense that there's some pushback due to a Google property requesting a
feature that Google engineers are trying to get into the browser, but I
think that Gmail is emblematic of all large web apps. Shared workers have
their place, but that place is not sharing the UI code for large apps.

I saw a comment that forcing multiple windows of one application into the
same process is undesirable. I disagree. Gmail is not a CPU-bound
application. We believe that the savings of having one JS heap, one request
queue, one data store, etc. would outweigh the benefits of process
isolation.

3) Should SharedScript be added to WebKit?

I'm not a WebKit developer, so I'm not as qualified to comment. However, I
believe that SharedScript is a feature that many apps would use. We tried to
come up with a representative set of examples in the spec. We're happy to
come up with more. I don't believe that SharedWorkers will solve those
scenarios. I doubt that developers inside or outside of Google will move to
a totally async programming model.

Sorry that this initial mail is also a little scattered. I'll try to stay on
top of the conversation as it progresses, and will hopefully be able to
provide a perspective from the trenches of web development.

Michael


On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson <atwilson at google.com> 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.
>
> -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/924471ee/attachment.html>