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 <atwil...@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 <atwil...@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 <m...@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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
