Re: [webworkers] SharedWorker and ApplicationCache

On Sat, 7 Nov 2009, Anne van Kesteren wrote:
>
> We were wondering why there is a quite complicated resolution algorithm 
> to determine the ApplicationCache that belongs to the SharedWorker 
> rather than just passing the ApplicationCache to the SharedWorker at 
> creation time (i.e. as constructor argument). Is there anything that is 
> gained by the current model?

It's not that complicated; it's the same algorithm as you have for just 
going straight to a URL directly.


On Sat, 7 Nov 2009, Drew Wilson wrote:
>
> You may have two separate pages running from different app caches (or 
> version), each of which is trying to access the same shared worker, so 
> we don't want to tie it explicitly to a specific parent's app 
> cache/version.
> 
> It does seem a bit wonky, though - if you have one parent who has an app 
> cache that has two resources in it (a.js and b.js) and another parent 
> who has an app cache that has a different two resources in it (a.js and 
> c.js), it's non-deterministic which app cache the shared worker would be 
> associated with, and this could break apps.
> 
> I'm not sure that there's a good solution for this, given that manifests 
> can only be associated with an HTML resource.

It's the same problem with opening an <iframe> to a page that is in 
multiple caches.


On Sat, 7 Nov 2009, Michael Nordman wrote:
>
> I've been wondering if SharedWorkers should have a means of establishing 
> an appcache similar to how pages can via the <html manifest='x'> 
> mechanism.
> 
> My mental model is that a shared worker is very much like a top-level 
> page with respect to appcaches, but that means for a shared worker to 
> express/establish its appcache is missing.

You don't need to specify the appcache in the shared worker, because the 
user is never going to open a worker directly. Thus, the author just has 
to make sure to mention the worker in the app manifest, and it'll be fine. 
It can get hairy if you have multiple manifests that mention the same 
shared worker, and I guess in that situation you might want to have a 
manifest declared so that there can always be one version of the shared 
worker, shared by all the apps, but then you can emulate that for now 
using an iframe that just declares a manifest with just the shared worker 
(and that iframe can also be used to proxy access to the shared worker for 
other domains, if necessary), so I don't think we need to add it to the 
spec straight away -- we can add it later if it really would be useful.


On Sat, 7 Nov 2009, Drew Wilson wrote:
>
> Yeah, I thought about this some back when I was trying to piece together 
> a proposal for persistent workers. I suppose you could pass an optional 
> manifest URL to the SharedWorker constructor, with appropriate 
> restrictions on different pages creating the same SharedWorker but with 
> different manifest URLs. Since there's already an optional name 
> parameter, you could always require the name to be specified if you are 
> specifying an app cache URL (so the third argument to the constructor 
> would always be the manifest URL).

On Sat, 7 Nov 2009, Michael Nordman wrote:
>
> I was thinking something more in parallel with how HTML pages establish 
> the appcache association. There are very precise algorithms that define 
> how this cache association is to be performed for 'master-entry' pages. 
> I think ll of those algorithms could apply to shared worker scripts, if 
> only shared worker scripts possessed a means to declare an association 
> with a manifest file. What is missing is a means for the worker script 
> to declare that association.

I agree with Michael that this would make more sense as an in-file marker.


On Mon, 9 Nov 2009, Alexey Proskuryakov wrote:
> 
> Don't shared workers depend on HTML documents for network loading?

No.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 1 December 2009 09:17:18 UTC