> > I think it makes sense to treat dedicated workers as simple subresources,
not separate browsing contexts, and that they should thus just use the application cache of their parent browsing contexts. This is what WebKit does, according to ap. > I've now done this in the spec. Sounds good. I'd phrase it a little differently though. Dedicated worker do have a browsing context that is distinct from their parents, but the appcache selected for a dedicated worker context is identical to the appacache selected for the parents context. > > For shared workers, I see these options: > - Not allow app caches, so shared workers don't work when offline. That seems bad. > - Same as suggested for dedicated workers above -- use the creator's cache, so at least one client will get the version they expect. Other clients will have no idea what version they're talking to, the creator would have an unusual relationship with the worker (it would be able to call swapCache() but nobody else would), and once the creator goes away, there will be a zombie relationship. > - Pick an appcache more or less at random, like when you view an image in a top-level browsing context. Clients will have no idea which version they're talking to. > - Allow workers to specify a manifest using some sort of comment syntax. Nobody knows what version they'll get, but at least it's always the same version, and it's always up to date. > Using the creator's cache is the one that minimises the number of clients that are confused, but it also makes the debugging experience most differ from the case where there are two apps using the worker. > Using an appcache selected the same way we would pick one for images has the minor benefit of being somewhat consistent with how window.open() works, and we could say that window.open() and new SharedWorker are somewhat similar. > I have picked this route for now. Implementation feedback is welcome in determining if this is a good idea. Sounds good for now. Ultimately, I suspect that additionally allowing workers to specify a manifest using some sort of syntax may be the right answer. That would put cache selection for shared workers on par with how cache selection works for pages (not just images) opened via window.open. As 'page' cache selection is refined due to experience with this system, those same refinements would also apply to 'shared worker' cache selection.
