[webkit-dev] SharedWorkers alternate design

[Michael Nordman]

How workers and appcaches interact has been discussed on the WHATWG
list. Ian's "Worker feedback" message on 3/27/09 tried to tie things
up for the time being. I think where he left things was a reasonable
stepping stone, although the answers to the questions being asked here
about updates were not entirely resolved.

> 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.

The use case are workers that can be considered "faceless
applications". They are versioned independently of user interfaces
that make use of them thru a stable message based API.

> 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?

I think the intent of the current spec is that a new instance would
not be created provided there is an existing instance already running.
How to reload an existing worker to utilize new resources in an
updated cache was left as an exercise to the reader.

At least that's my understanding of the current spec.


2009/6/1 Drew Wilson <atwilson at google.com>:
>
>
> 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
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>