[webkit-dev] GlobalScript in WebKit

[Michael Davidson]

On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson <ian at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/45deb18c/attachment.html>