- From: Michael Nordman <michaeln@google.com>
- Date: Wed, 25 Mar 2009 14:11:07 -0700
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). * 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.) 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? On Wed, Mar 25, 2009 at 11:36 AM, Drew Wilson <atwilson at google.com> wrote: > Awesome, thanks. That feels in line with how I was viewing the issue - the > big problem (as you note below) is that the AppCache mechanism breaks down > when you have two different top-level browsing context sharing a single > resource (SharedWorkers). > I'm working on a proposal for persistent workers (shared workers that keep > running after the browser is closed, and launch on startup) and so how these > workers interact with the application cache is of great interest to me. One > approach that I'm considering is giving each persistent worker its own app > cache, so rather than inheriting a cache from any given browsing context it > would be responsible for managing its own offline resources. This seems to > have a bunch of advantages, and might also be applicable to normal shared > workers. > > > -atw > > 2009/3/25 Michael Nordman <michaeln at google.com> > > There hasn't been much discussion of this yet... a few comments on the list >> between august and november of 2008... >> > > > [michaeln] How do workers and appCaches interact? >> > > >> > > [ian] workers are associated with browsing contexts, so they go >> through the >> > > normal app cache networking changes. This probably interacts badly >> > > with shared workers used from different app caches. We should probably >> > > study this more. >> > > >> > > Aaron, Maciej, others, do you have opinions on how these should >> > > interact? >> > >> > [michaeln] Seems reasonable to spec that dedicated workers are very >> related to >> > their owner, execute in a child browsing context, and consequently >> > inherit the same appCache. >> > >> > Seems reasonable to spec that shared workers are associated with a >> > browsing context that is very distinct from their clients. Akin to an >> > "auxiliary top-level browsing context". >> >> [ian] The above seems reasonable... >> >> >> > Beyond that it gets less clear. >> > >> > Do sharedWorker.js documents need a <html manifest='url'> equivalent? >> >> They don't have one today. I don't really want to add one... >> >> >> > Should a shraredWorker loaded from appCacheA be distinct from a named >> > shared worker loaded from appCacheB or from the network? >> >> That seems like a reasonable possibility too... >> >> >> I haven't fixed this yet. >> >> >> >> On Tue, Mar 24, 2009 at 6:14 PM, Drew Wilson <atwilson at google.com> wrote: >> >>> I'm trying to understand the ApplicationCache spec as it applies to >>> workers, but I didn't find anything promising when I searched the archives. >>> Is ApplicationCache intended to apply to workers? The application cache API >>> isn't available to workers, but I'm guessing the intent is that if an >>> application creates a dedicated worker then worker requests (like >>> importScripts()) would come out of the cache inherited from the parent >>> document. If not, then it seems impossible to support running workers when >>> in offline mode. >>> >>> Since SharedWorkers are shared by multiple windows, there's some >>> ambiguity about which app cache it should use (perhaps always the one from >>> the creator window?) - it seems like an app might get different >>> SharedWorkers() loading from different app caches depending on the order in >>> which different windows create them, which seems like a dubious outcome. Has >>> this been discussed previously? >>> >>> -atw >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090325/d40042f6/attachment.htm>
Received on Wednesday, 25 March 2009 14:11:07 UTC