On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt <oli...@apple.com> wrote:
> > 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<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. > > > 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); > Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. > 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. > This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). Cheers, -Darin > > 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 <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 > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev