02.06.2009, в 1:29, Michael Nordman написал(а):
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.
Is it really possible for a SharedWorker to be versioned independently
from UI? When a document calls a SharedWorker constructor, the worker
script is loaded from the document's appcache (because all subresource
loading goes through appcache, of course). So, its source always
matches the UI version. Even if there is a newer version of appcache
already loaded, the document's one will be used for loading
subresources.
When a worker's script is referenced from several appcaches, this
becomes somewhat trickier. As Andrew correctly mentioned, the version
used will depend on which application was the first to construct the
SharedWorker. But how is it a problem if we require SharedWorkers to
implement a stable messaging API?
Given that SharedWorkers are versioned together with UI, and that
loading a new main resource in UI always invokes update process, I'm
not sure if there are any use cases that require workers to call
update() on their own. This is quite similar to how faceless helpers
in large native application suites work - I don't think that they ever
check for updates, it's only done at application startup.
- WBR, Alexey Proskuryakov
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
