[webkit-dev] GlobalScript in WebKit

Tue Dec 1 09:15:03 PST 2009

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. This is especially relevant for long-lived
(comet-like) connections. We also know how many simultaneous connections our
servers can handle, so we would like to manage this independently of the
number of windows the user has open.

> On Nov 30, 2009, at 7:13 PM, Michael Davidson wrote:
>
> Thanks a lot for sharing your perspective. Hearing it directly is helpful.
> Would you be willing to share your thoughts with one of the standards
> mailing lists? One of our concerns is the apparent skepticism of other
> browser implementors towards this idea.
>
>
Of course. I believe there have been long threads on whatwg about this
already. Ian Hickson stated a belief that SharedWorkers are sufficient,
which pretty much killed the conversation. I'm happy to join in again, but I
think having two browser implementors on board would go a long way to
helping the standards process.

>
> The thread has gotten a little broad, so apologies if I miss something. It
> seems to me there are a few separate questions being discussed:
>
> 1) In isolation, is SharedScript a good idea?
>
> People seem neutral-to-positive, so I won't spend time addressing this.
> It's clearly something that would be useful. There are open questions about
> how it works with Chrome's process model, but I think that's mostly just
> implementation details. In a world where SharedWorkers never existed, I
> think people would be jumping on this.
>
>
> 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. Opportunistic
sharing that fails is equivalent to running two separate browser on the same
machine. The app has to handle that situation anyway.

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. However, we will always have to handle the case where a
user logs in with multiple browsers. Can you think of a scenario where
failed opportunistic sharing would be handled differently from the multiple
browser case?

>
> Are you concerned mainly about users opening a brand new additional GMail
> window with some already open, or cases of windows created by an original
> GMail window, like the tear-off chat window?
>

Both.

> (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.

> Even if this is only part of what you are interested in, it could be an
> easy way to prototype this programming model and quantify the benefits in
> terms of speed and memory use. Or if you've tried that experiment already,
> it would be useful to hear the results. I'm guessing it's not in production
> GMail since tearing off a chat window is fairly slow and shows a progress
> bar.)
>
>
I have code running that drives a tearoff window from the main window and
simply closes all tearoffs when the main window closes. The latency
improvement is huge. We plan on launching this feature regardless of the
outcome of SharedScript. The feature we're discussing would allow two
improvements. First, tearoffs wouldn't have to close when the main window
closes. Second, new instances of Gmail would be as fast as the new fast
tearoffs. There is obviously user demand for multiple full Gmail views. A
Googler implemented the multiple inbox lab to satisfy this demand, but many
people still use multiple tabs open to Gmail to manage their mail. We could
make this work much more smoothly if we could share code, state, and network
connections.

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. Today
each window would have to show a notification. That one just occurred to me,
I'm sure we can come up with others.

Michael

 - Maciej
>
>
> I sense that there's some pushback due to a Google property requesting a
> feature that Google engineers are trying to get into the browser, but I
> think that Gmail is emblematic of all large web apps. Shared workers have
> their place, but that place is not sharing the UI code for large apps.
>
> I saw a comment that forcing multiple windows of one application into the
> same process is undesirable. I disagree. Gmail is not a CPU-bound
> application. We believe that the savings of having one JS heap, one request
> queue, one data store, etc. would outweigh the benefits of process
> isolation.
>
> 3) Should SharedScript be added to WebKit?
>
> I'm not a WebKit developer, so I'm not as qualified to comment. However, I
> believe that SharedScript is a feature that many apps would use. We tried to
> come up with a representative set of examples in the spec. We're happy to
> come up with more. I don't believe that SharedWorkers will solve those
> scenarios. I doubt that developers inside or outside of Google will move to
> a totally async programming model.
>
> Sorry that this initial mail is also a little scattered. I'll try to stay
> on top of the conversation as it progresses, and will hopefully be able to
> provide a perspective from the trenches of web development.
>
> Michael
>
>
> On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson <atwilson at google.com> wrote:
>
>> Following up, I think this highlights the distinct set of use cases that
>> shared workers and shared script address:
>>
>> SharedWorkers are a great platform for when you have a single database
>> that is shared across multiple instances of your web app, and you want to
>> coordinate updates to that database. I can imagine sharing a single
>> connection to the server, etc via SharedWorkers.
>>
>> SharedScripts are a good platform for when you want to share data/code
>> (for example, the immense body of Javascript used to implement the Gmail UI)
>> across multiple windows. I can't speak to whether passing a hidden iframe
>> between windows as was suggested in the other thread would address this use
>> case sufficiently.
>>
>> -atw
>>
>>
>> On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson <atwilson at google.com> wrote:
>>
>>> I believe that the offline gmail team uses the Gears flavor of shared
>>> workers and is planning to migrate to the HTML5 version once DB access is
>>> supported from within worker context in shipping browsers.
>>>
>>> So I guess that Gmail would be a candidate app that has asked for both.
>>>
>>> -atw
>>>
>>>
>>> On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak <mjs at apple.com>wrote:
>>>
>>>>
>>>> On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:
>>>>
>>>>  I don't think it's correct to say that SharedWorkers are not useful and
>>>>> "we need a SharedScript instead". They are different things and can address
>>>>> different use cases. For example, SharedWorker is great to make sure there
>>>>> is only one 'app instance' running - exactly because it is shared
>>>>> inter-process, it can be used as a "inter-process synchronization primitive"
>>>>> to control how many app instances are opened. SharedScript is a container
>>>>> for data and code shared between pages that comprise a "web application" and
>>>>> normally run in the same process. As in native apps, whether or not multiple
>>>>> instances of the app can run at the same time depends on the author of the
>>>>> app, and can be done either way.
>>>>>
>>>>
>>>> Are there any Web apps at Google or elsewhere currently using
>>>> SharedWorker? Would any of them still use it if they could switch to
>>>> SharedScript? Has any app team specifically requested support for *both*
>>>> SharedWorker *and* SharedScript? (Serious questions, since the justification
>>>> for SharedScript is largely based on Web developer feedback.)
>>>>
>>>> Note: if SharedScript was really globally shared it could be used to
>>>> implement shared workers - simply have the SharedScript manage the per-app
>>>> Workers.
>>>>
>>>> Regards,
>>>> Maciej
>>>>
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/81f9918e/attachment.html>