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