[webkit-dev] GlobalScript in WebKit

[Dmitry Titov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/06175688/attachment.html>