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

[whatwg] AppCache and SharedWorkers?

From: Drew Wilson <atwilson@google.com>
Date: Wed, 25 Mar 2009 15:01:21 -0700
Message-ID: <f965ae410903251501r38c132bw2cc5ec40649535bd@mail.gmail.com>
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.

-atw


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090325/b53f6b4c/attachment.htm>
Received on Wednesday, 25 March 2009 15:01:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT