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 <dim...@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 <gga...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
