On Nov 30, 2009, at 6:16 PM, Drew Wilson 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.
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.
Sharing an out-of-document HTMLIFrameElement would almost even account
for timers and the like, except that currently in WebKit a frame's
Window does not exist and its contents are not loaded if the frame is
not rendered.
- Maciej
-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
