<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div class="gmail_quote"><div>Sorry, I think you misunderstand. &nbsp;The way Chrome processes are divided is an implementation detail, but it is an important one. &nbsp;I think it is folly to ignore it when designing web APIs. &nbsp;We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. &nbsp;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.</div></div></blockquote><div><br></div><div>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. &nbsp;Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div> &nbsp;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.</div>
</div></div></blockquote><div><br></div><div>This is true, but I don't think it is a big deal. &nbsp;Processes are roughly divided up into browsing units. &nbsp;You start a new browsing unit by opening a new tab and navigating it. &nbsp;By doing so, you are creating a separate world that cannot see other worlds. &nbsp;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).</div></div></blockquote><div><br></div><div><br></div><div>I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? &nbsp;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.</div><div><br></div><div>--Oliver</div><div><br></div></div></body></html>