[webkit-dev] GlobalScript in WebKit

[Drew Wilson]

As an aside (that doesn't necessarily detract from your point) I'd say that
the WebWorker spec is fairly clear in intent: that there will be a single
sharedworker per domain/name within a given UserAgent. You'd have to parse
the idea of a user agent fairly finely (i.e. treat separate Chrome processes
as different user agents) to conclude that cross-process sharing is an
implementation detail and not mandated by the specification.

-atw

On Mon, Nov 30, 2009 at 3:43 PM, Dmitry Titov <dimich at chromium.org> 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.
>
> Multi-process browsers are bringing more complexity (and benefits). Not all
> technical issues<http://www.chromium.org/developers/design-documents/process-models>are completely resolved in Chrome's implementation, and we might need (or
> not) some mechanism of saying that a bunch of pages form "an application"
> and should share a process. Right now, it's unclear if such mechanism even
> needed though.
>
> I agreed with you to remove the implementation details from the doc because
> indeed they do not belong there. Not that they are not existing. For
> example, the fact that in Chrome SharedWorkers are indeed inter-process
> theoretically could be different. WebWorkers spec does not specify where and
> how to look for instances of SharedWorkers, although it implies some useful
> degree of sharing. The fact that in Chrome they are shared across all
> processes is a detail of Chrome implementation.
>
> Dmitry
>
> On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>
>> > Just a note:
>> >
>> > In Chrome, a SharedWorker is reachable from any WebKit process, whereas
>> a SharedScript would only be reachable within a WebKit process.  This is an
>> interesting distinction, and I can imagine some use cases for SharedWorker
>> that SharedScript could not address.  (This distinction arises because we
>> did not want to build a script proxy between WebKit processes as that would
>> be quite costly.)
>> >
>> > For example, suppose you wanted to have only one instance of a web app
>> responsible for manipulating a database or communicating with a server.
>>  There's no guarantee that multiple instances of a web app would all run in
>> the same WebKit process.
>>
>> Actually, I objected to that distinction, and it has been removed from the
>> specification.
>>
>> You can find the discussion here:
>> https://bugs.webkit.org/show_bug.cgi?id=31317.
>>
>> And the specification here:
>> http://docs.google.com/View?id=dxv3cth_4gvggh3gh.
>>
>> I'm concerned that a lot of Chrome engineers are speaking for "Google",
>> but they don't really have their stories straight. First, a group of Chrome
>> engineers said that "Google" needed SharedWorker, so it was implemented in
>> WebKit. Now, a group of Chrome engineers says "Google" can't use
>> SharedWorker, and needs SharedScript instead. So, we're gearing up to
>> implement that. Meanwhile, not all Chrome engineers agree about what
>> SharedWorker is or why it is that way, and we can reasonably assume that the
>> actual Google engineers who have asked for these technologies disagree even
>> more.
>>
>> It's OK to disagree and hash out ideas. But it's a little weird to try to
>> dictate the direction of WebKit in the name of "Google" and "several major
>> apps with millions of users", when that standard seems to blow whichever way
>> the wind goes.
>>
>> Geoff
>
>
>
> _______________________________________________
> 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/622b1f33/attachment.html>