> 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).
If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. > But how is it a problem if we require SharedWorkers to implement a stable > messaging API? There are other interfaces to consider. The client<->server messaging interface used by the worker to talk to the mother ship. And more significantly, the localstorage schema used by the worker. Consider a "newer" version of a shared worker alters a local database schema. If an "older" version of the worker is pinned in some other appcache, that schema change is likely incompatible with the that older worker. 2009/6/1 Alexey Proskuryakov <a...@webkit.org>: > > 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