W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] AppCache and SharedWorkers?

From: David Levin <levin@google.com>
Date: Wed, 25 Mar 2009 17:09:52 -0700
Message-ID: <b902e34a0903251709y136aeea6j23f75e2a337fee4b@mail.gmail.com>
On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson <atwilson at google.com> wrote:

> On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman <michaeln at google.com>wrote:
>> The appcache spec has changed since the ian and i sent these old messages.
>> Child browsing contexts (nested iframes) no longer "inherit" the appcache of
>> their parent context (frame) by default.
>> How's this for a starting point for how these things intereract...
>> * Dedicated worker contexts should be associated with an appcache
>> according to the same resource loading and cache selection logic used for
>> child browsing contexts. (So just like navigating an iframe).
> Since dedicated workers are tightly tied (1:1) with a specific top-level
> browsing context, I'd say that they should use the same appcache as the
> document that started them.
>> * Shared (or persistent) worker contexts should be associated with an
>> appcache according to the same resource loading and cache selection logic
>> used for top-level browsing contexts. (So just like navigating a window.)
> That may make sense for Shared workers, I think. For persistent workers I
> think this is a problem - persistent workers need a way to manage their own
> app cache, since they are not guaranteed to have any open windows/documents
> associated with them. My concern about this is that app cache manifests are
> only specified via <manifest> html tags, which makes them only applicable to
> HTML documents (you can't associate a manifest with a worker since there's
> no document to put the manifest tag in).
>> At least one question, I'm sure there are others...
>> What does a shared (or persistent) worker do when the appcache its
>> associated with is updated? Is there a way to "reload" itself with the new
>> script in the latest version of the appcache? What about message ports
>> between the worker and other contexts?
> One could imagine that the worker would reload its javascript via
> importScripts(). It kind of assumes that the script is idempotent, though.

Similarly one could use nested workers (which I like because it gives the
new script a new global object). The shared/persistent worker would start a
nested worker.  Then for a reload, it could shut down the current nested
worker and start up a new one.

Regarding message ports, it would be up to the implementation to decide if
the shared/persistent worker followed a pointer to implementation pattern or
if it handed out message ports directly to the nested worker.


> -atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090325/74ccd720/attachment.htm>
Received on Wednesday, 25 March 2009 17:09:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:10 UTC