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.<div><br></div><div>
How's this for a starting point for how these things intereract...<div><br></div><div>* 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).</div>
<div><br></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">* 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.)</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">At least one question, I'm sure there are others...</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">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?</span></div>
<div><font class="Apple-style-span" color="#500050"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><br><div class="gmail_quote">On Wed, Mar 25, 2009 at 11:36 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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).<div>
<br></div><div>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. </div>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br>
<div><br></div><div>-atw<br><br><div class="gmail_quote">2009/3/25 Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span><div><div></div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There hasn't been much discussion of this yet... a few comments on the list between august and november of 2008...<div><br></div><div><span style="border-collapse:collapse"><div style="color:rgb(80, 0, 80)">
> > > [michaeln] How do workers and appCaches interact?<br>> ><br>> > [ian] workers are associated with browsing contexts, so they go through the</div><div style="color:rgb(80, 0, 80)">> > normal app cache networking changes. This probably interacts badly<br>
> > with shared workers used from different app caches. We should probably<br>> > study this more.<br>> ><br>> > Aaron, Maciej, others, do you have opinions on how these should<br>> > interact?<br>
><br>> [michaeln] Seems reasonable to spec that dedicated workers are very related to</div><div style="color:rgb(80, 0, 80)">> their owner, execute in a child browsing context, and consequently<br>> inherit the same appCache.<br>
><br>> Seems reasonable to spec that shared workers are associated with a<br>> browsing context that is very distinct from their clients. Akin to an<br>> "auxiliary top-level browsing context".<br><br>
</div><span style="color:rgb(80, 0, 80)">[ian] </span>The above seems reasonable...<br><div style="color:rgb(80, 0, 80)"><br><br>> Beyond that it gets less clear.<br>><br>> Do sharedWorker.js documents need a <html manifest='url'> equivalent?<br>
<br></div>They don't have one today. I don't really want to add one...<br><div style="color:rgb(80, 0, 80)"><br><br>> Should a shraredWorker loaded from appCacheA be distinct from a named<br>> shared worker loaded from appCacheB or from the network?<br>
<br></div>That seems like a reasonable possibility too...<br><br><br>I haven't fixed this yet.</span></div><div><div></div><div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse"><br>
</span><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 6:14 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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.<br>
</div><div><br></div><div>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?</div>
<div><br></div><div>-atw</div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>