[webkit-dev] GlobalScript in WebKit

[Ian Hickson]

On Tue, 1 Dec 2009, Michael Davidson wrote:
> On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> >
> > Would it be fair to say the goal for SharedScript is just to share 
> > code and data (to reduce memory use of multiple instances of GMail), 
> > and not network connections, timers, or other APIs based on async 
> > callbacks (assuming those either remain per-Window or are in the 
> > SharedWorker)? If so, then it would pretty much completely be handled 
> > by sharing of some arbitrary JavaScript object, possibly arranged by 
> > SharedWorker.
>
> 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.


> > Always-shared vs. opportunistically-sometimes-shared seems like a big 
> > difference, more than just implementation details. It has a direct 
> > impact on how to correctly author content using this mechanism.
> 
> I'm not sure that this is true. Users can always run multiple browsers with
> different profiles, or run browsers on different machines.

Using different machines, different browsers, or different profiles has 
some pretty major differences with using different tabs (processes) 
in Chrome: only in the latter would one common database, storage, and 
cookie infrastructure be shared, only in the latter would the HTTP 
per-origin connection limit be shared, only in the latter would 
application caches and HTTP caches be shared, etc.


> In a perfect world, we'd like to be able to hint that a toplevel 
> navigation belongs to a set of pages that should share a process. That 
> way if the user navigates to, say, http://mail.google.com, we can tell 
> the browser that we'd like it to be rendered in an existing process if 
> one exists. That would lead to maximal sharing.

Since iframes have to share a process even across origins, and since 
window.open() from an iframe has to share the process of the opener, it is 
trivial to engineer a situation where it's not possible to share the 
process. This kind of situation would commonly arise with pages like 
iGoogle that embed a GMail gadget.


> > (I ask because windows with a pre-existing relationship like 
> > parent/opener could already share code and data if they chose to, 
> > without any new browser features. Just pass the functions or objects 
> > of your choice to the newly opened window.
> 
> 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.


> A third improvement: When we adopt the HTML5 notification API for 
> showing users new mail or incoming chat notifications we will only show 
> one notification regardless of the number of Gmail tabs that are open.

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'