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
