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&#39;t have to proxy messages. It&#39;d have to have some app-specific mechanism to get them all back when it wants to restart the nested worker, though :)<div>
<br></div><div>-atw<br><br><div class="gmail_quote">On Wed, Mar 25, 2009 at 5:09 PM, David Levin <span dir="ltr">&lt;<a href="mailto:levin@google.com">levin@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman <span dir="ltr">&lt;<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer &quot;inherit&quot; the appcache of their parent context (frame) by default.<div><br></div><div>



How&#39;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></blockquote><div><br></div></div><div>Since dedicated workers are tightly tied (1:1) with a specific top-level browsing context, I&#39;d say that they should use the same appcache as the document that started them.</div>

<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div>
<div><br></div><div><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></div></div></blockquote><div><br></div></div><div>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 &lt;manifest&gt; html tags, which makes them only applicable to HTML documents (you can&#39;t associate a manifest with a worker since there&#39;s no document to put the manifest tag in).</div>

<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">At least one question, I&#39;m sure there are others...</span></div>



<div><span style="border-collapse:collapse"><br></span></div><div><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 &quot;reload&quot; 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></blockquote><div><br></div></div><div>One could imagine that the worker would reload its javascript via importScripts(). It kind of assumes that the script is idempotent, though. </div><div></div></div></blockquote>

<div><br></div></div></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Dave</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div>-atw</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span style="border-collapse:collapse"></span></div><div><div></div><div>
<div><br></div></div></div></div></blockquote></div>
</blockquote></div><br>
</blockquote></div><br></div>