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. At the very least, it will vastly improve the situation we have today. The iGoogle gadget that you mention later would not use SharedScript, FWIW. The mechinism that it uses to get data from Gmail is entirely different. 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. > As mentioned elsewhere on this thread, this isn't a great solution. XHRs > > and timers, specifically, need to find a new parent window when one > > window closes. I do have this working for Gmail tearoffs right now, but > > all windows have to close when the main window closes. > > 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? I can do some experiments with existing browsers, but I would be surprised if a reference to an iframe were enough to keep it alive when its containing document is closed. > You can't do that with SharedScript, since it's not guaranteed to be > unique across the browser. However, SharedScript misleads people into > thinking that they can do that, which is one reason that I am skeptical > that it is a good idea. > > So this might not have been the best-considered example. The ability to share network connections is a better one, where failure to share isn't catastrophic, but success has benefits. The goal of the proposal is to make sharing as easy as possible and to allow apps to reduce the amount of resources they use. The goal is not to mislead people into thinking that SharedScript is bulletproof sharing, which is why the spec says that sharing might fail. I believe, from talking to web app developers, that simple sharing that might fail is a desirable feature. It is true that if you absolutely need to guarantee sharing that shared workers are a better solution, but for our app we don't need that guarantee and find workers unsuitable for UI code for reasons stated earlier in the thread. Michael
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
