[webkit-dev] SharedWorkers alternate design

[Alexey Proskuryakov]

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