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 :)<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"><<a href="mailto:levin@google.com">levin@google.com</a>></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"><<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 class="gmail_quote"><div>On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></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 "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></blockquote><div><br></div></div><div>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.</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 <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).</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'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 "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></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>