[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

We should probably discuss this point on the whatwg list, but I'll give you
my understanding of why this is desirable:
1) Since SharedWorkers aren't explicitly tied to a specific Document, it
doesn't make sense to have them possibly get loaded from an out-of-date
version of the app cache. If you have two separate documents running from
different caches, it's weird (and indeterminate) if the version of the cache
used to load the SharedWorker script is dependent on which one happens to
call "new SharedWorker()" first.

2) Since SharedWorkers may outlive a given document, it makes sense to allow
them to manage their own appcache state, especially once we start supporting
PersistentWorkers (which may run for days, weeks, or years).

3) SharedWorkers may have a different criteria determining when it wants to
update its app cache.

As for what happens to a SharedWorker whose cache was updated? My
presumption is that all future resource loads would use that cache. At that
point, the SharedWorker has a few different things it could do:

   - Reload all of its scripts again using importScripts(). This implies
   that its script loading is idempotent, but that's not too hard to do.
   - Send messages to all of its client documents letting it know that it is
   shutting down, then invoke close() to shut itself down. The client documents
   can re-create the SharedWorker the next time they want one. This is
   inherently race-y, though, since you can't easily coordinate the shutdown of
   the worker with instantiations of new ones.
   - Do nothing at all

-atw

2009/6/1 Alexey Proskuryakov <ap at webkit.org>

>
> 22.05.2009, в 3:20, Drew Wilson написал(а):
>
>
>    - SharedWorkers have explicit access to the ApplicationCache APIs,
>    while dedicated Workers merely inherit the ApplicationCache from their
>    parent window.
>
> What is the use case for this? It doesn't seem useful to me - to invoke
> update explicitly, one normally needs to have UI anyway, at which point it's
> much easier to call update() directly from a page.
>
> A tangentially related question: what will happen to a SharedWorker whose
> cache got updated? Will the repository use a new source for new instances,
> while the old ones will continue to run? Looks like there is a significant
> potential for mistakes here, as scripts won't normally expect several
> instances of the same SharedWorker to be active.
>
> - WBR, Alexey Proskuryakov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090601/afdfe53d/attachment.html>