On Mon, Nov 30, 2009 at 6:16 PM, Jeremy Orlow <[email protected]> wrote:
> On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt <[email protected]> wrote: > >> >> On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: >> >> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <[email protected]> wrote: >> >>> >>> 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. >>> >>> >>> It is wrong to design an API based on architectural decisions of your >>> existing browser -- you should be making decisions based on what the >>> developers actually need. Being hard for the browser to implement is a >>> secondary concern next to being hard for the end developer to use. >>> >>> 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). >>> >>> >>> >>> I have a (simple) question: If Global/SharedScript is not guaranteed to >>> be either Global or Shared, what is it trying to accomplish? It's not >>> possible for any developer to use them for shared state as they can't >>> guarantee that a normal user, doing normal things, is not going to end up >>> with distinct instances of this "shared" state. >>> >> >> Please look at the use cases in the spec. They're pretty much all an >> optimization to cut down on resource utilization and load times by sharing >> more state. >> >> As a side note, I would expect that many SharedScript users would also >> use SharedWorkers for a lot of the non-UI logic including storage and >> network. >> >> Also note that the possibility of having multiple SharedScript instances >> within one browser is pretty much the same as the possibility of the user >> having multiple browsers open on the same computer. >> >> The point i was getting at is that unlike the typical way to get this >> situation (running multiple browsers) is not a common end user behaviour, >> but Chrome's model makes it very easy -- as far as I am aware if I open two >> windows independently and navigate both to example.com i will end up with >> two processes, thus ending up with two instances of the same SharedScript. >> >> I actually just did a quick test, and I am unsure how I can actually open >> two windows in such a way that Chrome would end up using a single >> SharedScript instance -- both new window and new tab result in separate >> processes, the only logical case that would allow multiple windows to end up >> sharing an instance (and thus gaining any benefit at all from this >> feature) would be by opening a window from an original source page, in which >> case an invisible iframe could trivially be passed around, and has all of >> the advantages of SharedScript, none of the disadvantages, and works in all >> existing browsers. >> > > The usage of SharedScript is a strong hint to the browser that future tabs > for that origin should be opened in the same process. With such a > heuristic, you only run into trouble when a particular origin doesn't > immediately use the SharedScript and a user opens up another tab in the mean > time. This could be mitigated by the browser saving which origins use > SharedScript somewhere. > [from the right email address] Just my two cents, but I don't think the browser's process model should change based on a web site's use of SharedScript. This would end up causing all of the instances of a given web site to share a process, which can have bad implications for responsiveness. (Basically, it eliminates most of the benefits of having a multi-process browser if the user visits a lot of pages from the same site.) I haven't been following the SharedScript discussion closely enough, but I was under the impression that it was mainly targeted at pages opened directly from existing pages. If the user creates separate windows and navigates them to the same site independently, I would argue that those should not share the same SharedScript. Charlie > Has anyone really sat down and compared the use cases given in the spec to >> the behaviour of users? eg. to see if the model you're talking about would >> actually provide any real benefit in real world usage >> > > The spec was co-written by real world users (gmail engineers). > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
