[whatwg] Worker feedback

[Michael Nordman]

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090330/42ffdb88/attachment-0002.htm>