<br><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>01.06.2009,  22:37, Drew Wilson ():</div><div class="im"><div><br></div><blockquote type="cite"><span style="color:rgb(0, 0, 0)"><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>
</span></blockquote><div><br></div></div>I don&#39;t see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late.</div>
</div></blockquote><div><br></div><div>Not sure why that is &quot;too late&quot;? Can you clarify?</div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
<div></div><div><br></div><div>Besides, won&#39;t the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt.</div>
<div><br></div><div><div class="im"></div></div></div></blockquote><div><br></div><div>Why would a document using an old version of cache break if a newer SharedWorker is returned? Why is that any more of a problem than a document using a new version of cache breaking if an older SharedWorker is returned, which is what would happen if SharedWorkers inherited appcache from the first document that instantiated them?</div>
<div><br></div><div>It seems like there are several easy options available to apps:</div><div><br></div><div>1) Change the name of the shared worker if a non-backward-compatible change needs to be made to the worker script (so new documents don&#39;t share the same worker instance as old documents)</div>
<div>2) When updates are available, coordinate updates with all documents so everyone updates at once, possibly exiting the SharedWorker.</div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><br><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"><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></span></blockquote></div>All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won&#39;t break at update time.</div></div></blockquote>
<div><br></div><div>It might be tricky, although any application that does dynamic JS loading has to deal with versioning issues already. This is not particularly different.</div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div><br>
</div><div><div><div>A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). </div>
</div></div></div></blockquote><div><br></div><div>Why can&#39;t they reload the main script? Again, there&#39;s a need to be idempotent if you need to maintain some cached state, but it&#39;s not totally impossible.</div>
<div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><div>Or they can shut down and ask a document to re-create themselves - at which point, we can as well say that the document can update the cache.</div>
</div></div></div></blockquote><div><br></div><div>I&#39;m not arguing against this, I just don&#39;t see how it works when you have multiple documents each of which are running from different versions of the app cache, where the shared worker itself is attached to some arbitrary instance.</div>
<div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><div></div><div><br></div></div><div>Interaction of SharedWorkers and appcache, explicit or not, sounds like a major issue to me. It can significantly affect the design (or even make SharedWorkers not worth being added, if no acceptable solution is found).</div>
</div></div></blockquote><div><br></div><div>My design doc just reflects the current spec - I don&#39;t really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders.</div>
<div><br></div><div>I&#39;d be happy to start that conversation on the whatwg list, but to be honest I don&#39;t think I&#39;m quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns?</div>
<div><br></div><div>-atw</div></div><br>