[webkit-dev] GlobalScript in WebKit

[Oliver Hunt]

On Nov 30, 2009, at 3:43 PM, Dmitry Titov 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 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.

The Worker implementation behaviour is not really relevant to this conversation.  The issue is whether a browser implements a spec in a correct manner, that's why implementation is not described.  A worker for instance may be per thread, per process, or may not even represent a separate machine thread and could be implemented by in software just running each task in sequence (assuming a sufficiently careful implementation, etc, etc).

The issue we're discussing however was what Darin bought up -- should a multiprocess browser be allowed to have multiple distinct instances of the same Global/SharedScript?  the answer is clearly no (and that concept has been removed from the spec);  The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared.

The resultant implication is that a "Shared" or "Global" script would have not need to be shared at all and each page could have it's own copy -- effectively degenerating to a glorified iframe.

I would consider it to be a warning sign of potential badness in a spec if behaviour was being defined by perceived difficulty in implementing a feature, rather than on the desired end user behaviour.  In general I feel a spec should always favour complexity of implementation over complexity in use, after all if a feature is hard to implement it still only needs to be implemented a relatively small number of times (basically once per browser/engine) pushing the complexity on to end developers however then means thousands (millions?) of developers have to implement the same code and deal with the same complexity over and over again.  Obviously if there's an option to avoid any complexity that would be best, but i suspect that's unlikely to exist :-D

--Oliver

> 
> 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/d1fffe2b/attachment.html>