[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

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

>
> 01.06.2009, в 22:37, Drew Wilson написал(а):
>
> 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.
>
>
> I don't see how exposing DOMApplicationCache methods to workers can help
> this  - a worker will only be able to call DOMApplicationCache.update()
> after it has started, which is too late.
>

Not sure why that is "too late"? Can you clarify?


>
> Besides, won't the document using an old version of cache break if a newer
> SharedWorker is suddenly returned to it? The main idea of appcache is that
> all application resources are versioned, so if we see SharedWorkers as part
> of application, they should use the same cache version. And if they are
> independent entities with a stable API, using an out of date version for a
> while cannot hurt.
>
>
Why would a document using an old version of cache break if a newer
SharedWorker is returned? Why is that any more of a problem than a document
using a new version of cache breaking if an older SharedWorker is returned,
which is what would happen if SharedWorkers inherited appcache from the
first document that instantiated them?

It seems like there are several easy options available to apps:

1) Change the name of the shared worker if a non-backward-compatible change
needs to be made to the worker script (so new documents don't share the same
worker instance as old documents)
2) When updates are available, coordinate updates with all documents so
everyone updates at once, possibly exiting the SharedWorker.


>
> 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
>
> All of these options seem quite dangerous - it may be difficult for JS
> authors to write applications that won't break at update time.
>

It might be tricky, although any application that does dynamic JS loading
has to deal with versioning issues already. This is not particularly
different.


>
>

> A document can reload itself after updating, but SharedWorkers do not have
> a way to reload themselves. As you mentioned, they can reload imported
> scripts (but the main script will remain the same, which would be
> inconsistent).
>

Why can't they reload the main script? Again, there's a need to be
idempotent if you need to maintain some cached state, but it's not totally
impossible.


> Or they can shut down and ask a document to re-create themselves - at which
> point, we can as well say that the document can update the cache.
>

I'm not arguing against this, I just don't see how it works when you have
multiple documents each of which are running from different versions of the
app cache, where the shared worker itself is attached to some arbitrary
instance.


>
> Interaction of SharedWorkers and appcache, explicit or not, sounds like a
> major issue to me. It can significantly affect the design (or even make
> SharedWorkers not worth being added, if no acceptable solution is found).
>

My design doc just reflects the current spec - I don't really intend to be
the defender of said spec. As I said previously, I think this is the wrong
venue for us to describe issues with the spec - we should do it on the
whatwg list to include other stakeholders.

I'd be happy to start that conversation on the whatwg list, but to be honest
I don't think I'm quite understanding what your objections to the current
spec are. Would you mind kicking off that discussion with whatwg, outlining
your concerns?

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090601/d0fc6591/attachment.html>