[whatwg] AppCache and SharedWorkers?
atwilson at google.com
Wed Mar 25 15:01:21 PDT 2009
On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman <michaeln at google.com>wrote:
> The appcache spec has changed since the ian and i sent these old messages.
> Child browsing contexts (nested iframes) no longer "inherit" the appcache of
> their parent context (frame) by default.
> How's this for a starting point for how these things intereract...
> * Dedicated worker contexts should be associated with an appcache according
> to the same resource loading and cache selection logic used for child
> browsing contexts. (So just like navigating an iframe).
Since dedicated workers are tightly tied (1:1) with a specific top-level
browsing context, I'd say that they should use the same appcache as the
document that started them.
> * 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).
> At least one question, I'm sure there are others...
> What does a shared (or persistent) worker do when the appcache its
> associated with is updated? Is there a way to "reload" itself with the new
> script in the latest version of the appcache? What about message ports
> between the worker and other contexts?
importScripts(). It kind of assumes that the script is idempotent, though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg