- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Thu, 26 Mar 2009 13:58:56 +0300
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
Received on Thursday, 26 March 2009 03:58:56 UTC