> 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. --Oliver
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
