Just to provide some history... An intrinsic aspect of the SharedScript proposal is that scripting across the page / sharedScript boundary should be very fast. When coming up with the original proposal, we were careful to not require "singleton" semantics that would work against that goal (by requiring ipc proxy'ing and thread synchronization).
A "common context for all instances of a page" was intentionally not a goal since to make that gaurantee would be very much at odds with the performance goal. We tried to strike that balance between the scope of sharing and the promise of being performant by saying all pages within a "unit of related browsing contexts" are guaranteed to shared the same SharedContexts. In our proposal, the scope of shared is permitted to be wider, but is not required to be wider. A secondary concern is co-locating top-level pages to widen the scope of sharing beyond just the "unit of related browsing contexts". We've hand waved at "hints" that could help the browser accomplish that. On Tue, Dec 1, 2009 at 12:20 PM, Ian Hickson <i...@hixie.ch> wrote: > On Tue, 1 Dec 2009, Michael Davidson wrote: > > On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson <i...@hixie.ch> wrote: > > > On Tue, 1 Dec 2009, Michael Davidson wrote: > > > > No, we definitely want to share network connections. We'd like users > > > > to be able to have an arbitrary number of Gmail windows open without > > > > running into the browser connection limit. > > > > > > SharedScript doesn't give you that. Only a singleton mechanism can > > > give you that. > > > > Assuming that the same-process hinting works, it will give us that. > > The process hinting is not a guarantee. It is trivial to come up with > situations where different documents from the same origin are required to > end up in different processes. Furthermore, as a user, I would personally > much rather every GMail instance I open end up in a different process, for > the same reason that I'd like GMail and Google Calendar in different > instances, and Google Calendar and Google Search in different processes, > and Search and pages I get to from Search in different processes. > > > > At the very least, it will vastly improve the situation we have today. > > Either you "definitely want to share network connections", in which case > it doesn't give you what you want, or you don't need to share network > connections, in which case it seems no better than an <iframe>. > > > > The iGoogle gadget that you mention later would not use SharedScript, > > FWIW. > > Sure, but if it opens a true GMail window, that GMail window would have to > end up in the same process as the parent (so that the opener can be > accessed), which means it wouldn't be the same process as other GMail > tabs. It doesn't have to be an iGoogle gadget; any page that > window.open()s GMail would be in this situation as far as I can tell. > > > > I agree that anything that lives in an iframe is going to cause problems > > for SharedScript, but Gmail (like many webapps where having the URL > > exposed to the user is very important) doesn't allow itself to be in an > > iframe. > > It prevents it using script, which is too late since the process selection > happens long before the script runs. > > > > > It seems that you could just create an <iframe> instead of the > > > SharedScript, and pass it around onunload. > > > > Can an iframe live independently of its creating document? > > Per spec, yes, so long as it is owned by a living document it'll keep > existing. It should even work in browsers so long as you actually keep the > iframe grafted to an existing Window's Document -- hence the "pass it > around onunload" to keep it alive. > > > > The goal is not to mislead people into thinking that SharedScript is > > bulletproof sharing, which is why the spec says that sharing might fail. > > Yes, but people will think that's what it does, regardless of what it > does, because in most testing that's what it will do. It's like the > localStorage debacle -- we have to offer consistency guarantees because > people will assume them regardless of what the spec says. > > > > Anyway, I'm not trying to discourage experimentation here; I just wanted > to make it clear that SharedScript doesn't solve the shared networking > problem, because it can never be guarenteed to be a singleton -- indeed, > from the user's perspective, it would be undesireable for it to be > possible to make the browser always put all tabs from one origin into the > same process even if it was possible. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > 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
