On 26.03.2009, at 1:01, Drew Wilson wrote:
* 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.)
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).
Letting faceless background processes update themselves without user
consent is not necessarily desirable. I think that they need browser
UI for this, and/or associated HTML configuration pages that could
(among other duties) trigger application cache update.
So in my opinion, this is pretty much a sub-task of defining what UI
is necessary for persistent workers in the browser, not a question of
exposing application cache APIs to them.
- WBR, Alexey Proskuryakov
