[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

One more thing I'd follow up with is if we were to have a SharedWorker just
inherit an applicationcache from the first document that creates it, what
happens after that document closes? How can the SharedWorker update its
application cache if an update becomes available, since the only document
associated with that cache is now closed?
-atw

2009/6/1 Michael Nordman <michaeln at google.com>

> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090601/d8e6f083/attachment.html>