We should probably discuss this point on the whatwg list, but I&#39;ll give you my understanding of why this is desirable:<div><br></div><div>1) Since SharedWorkers aren&#39;t explicitly tied to a specific Document, it doesn&#39;t make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it&#39;s weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call &quot;new SharedWorker()&quot; first.</div>
<div><br></div><div>2) Since SharedWorkers may outlive a given document, it makes sense to allow them to manage their own appcache state, especially once we start supporting PersistentWorkers (which may run for days, weeks, or years).</div>
<div><br></div><div>3) SharedWorkers may have a different criteria determining when it wants to update its app cache.</div><div><br></div><div>As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do:</div>
<div><ul><li>Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that&#39;s not too hard to do.</li><li>Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can&#39;t easily coordinate the shutdown of the worker with instantiations of new ones.</li>
<li>Do nothing at all</li></ul><div>-atw</div><br><div class="gmail_quote">2009/6/1 Alexey Proskuryakov <span dir="ltr">&lt;<a href="mailto:ap@webkit.org">ap@webkit.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>22.05.2009, Χ 3:20, Drew Wilson ΞΑΠΙΣΑΜ(Α):</div><br></div><div class="im"><blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><ul>
<li>SharedWorkers have explicit access to the ApplicationCache APIs, while dedicated Workers merely inherit the ApplicationCache from their parent window.</li></ul></span></blockquote></div></div><div>What is the use case for this? It doesn&#39;t seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it&#39;s much easier to call update() directly from a page.</div>
<div><br></div><div>A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? Looks like there is a significant potential for mistakes here, as scripts won&#39;t normally expect several instances of the same SharedWorker to be active.</div>
<br><div> <span style="border-collapse:separate;border-spacing:0px 0px;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div>- WBR, Alexey Proskuryakov</div></div></span></div><br></div></blockquote></div><br></div>