[webkit-dev] SharedWorkers alternate design

[Michael Nordman]

> 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 <ap at 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
>
>
>