- From: David Levin <levin@google.com>
- Date: Wed, 25 Mar 2009 17:09:52 -0700
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. Dave > > -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