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
