[webkit-dev] GlobalScript in WebKit
Maciej Stachowiak
mjs at apple.com
Mon Nov 30 20:08:18 PST 2009
Hi Michael,
On Nov 30, 2009, at 7:13 PM, Michael Davidson wrote:
> Hi folks -
>
> I'm one of the Gmail engineers who worked on the SharedScript
> proposal. I thought I'd jump in and give my perspective as a
> developer.
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.
>
> 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.
>
> 2) Given that WebKit has committed to supporting SharedWorkers, is
> SharedScript a good idea?
>
> I think so. Background processing and sharing are orthogonal. It
> seems odd to me to require the former to get the latter.
>
> The problems that Drew pointed out upthread are real. Putting UI
> code in a SharedWorker is not feasible. Web apps are event driven.
> The user does something, the app responds by looking at its data and
> updating the UI. Introducing an async seam in between those
> operations is extremely difficult. I'm unaware of a UI framework
> that forces that programming model on developers. (I believe that
> Cocoa is the same - one UI thread that pumps messages, and new
> threads are only spawned at the developer's request. All we want is
> to have multiple windows that can work like that!) It's not that the
> cost of migrating Gmail to such a model would be high (although it
> would). The amount of code that we have that deals with the UI and
> needs to look at our shared state is huge. Sharing that code *and*
> the data model across windows would be a big win for Gmail latency.
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? (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. 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.)
- 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/20091130/ab336360/attachment.html>
More information about the webkit-dev
mailing list