[whatwg] AppCache and SharedWorkers?

[David Levin]

On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson <atwilson at google.com> wrote:

> 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?
>>
>
> One could imagine that the worker would reload its javascript via
> importScripts(). It kind of assumes that the script is idempotent, though.
>

Similarly one could use nested workers (which I like because it gives the
new script a new global object). The shared/persistent worker would start a
nested worker.  Then for a reload, it could shut down the current nested
worker and start up a new one.

Regarding message ports, it would be up to the implementation to decide if
the shared/persistent worker followed a pointer to implementation pattern or
if it handed out message ports directly to the nested worker.

Dave



>
> -atw
>
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090325/74ccd720/attachment-0002.htm>