- From: Drew Wilson <atwilson@google.com>
- Date: Wed, 25 Mar 2009 18:13:09 -0700
Good point - I like the idea of nested workers, especially if the SharedWorker uses the pattern where it just passes off all incoming message ports directly to the nested worker so it doesn't have to proxy messages. It'd have to have some app-specific mechanism to get them all back when it wants to restart the nested worker, though :) -atw On Wed, Mar 25, 2009 at 5:09 PM, David Levin <levin at google.com> wrote: > > > 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/b393cfe9/attachment.htm>
Received on Wednesday, 25 March 2009 18:13:09 UTC