> 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
