[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

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.


I don't think that's the intent of the spec:

If worker global scope is actually a
SharedWorkerGlobalScope<#sharedworkerglobalscope> object
(i.e. the worker is a shared worker), and there are any relevant application
caches that are identified by a manifest URL with the same origin as url and
that have url as one of their entries, *not* excluding entries marked as
foreign, then associate the worker global scope with themost appropriate
application cache of those that match.

I'm not at all certain what "most appropriate application cache" means, but
I *think* it means "most up-to-date cache", not "cache associated with the
constructing document". I think that's the point that this discussion hinges
upon. Michael, do you know what that phrase means?

I don't understand our AppCache implementation well enough to know how hard
it will be to implement this behavior, given that we are proxying our loads
to a parent document.

-atw



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