- From: Michael Nordman <michaeln@google.com>
- Date: Sat, 7 Nov 2009 10:47:55 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Drew Wilson <atwilson@google.com>, WebApps WG <public-webapps@w3.org>
- Message-ID: <fa2eab050911071047p22df3354qcacd1aef7205490a@mail.gmail.com>
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. On Sat, Nov 7, 2009 at 9:14 AM, Drew Wilson <atwilson@google.com> 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. > > -atw > > > On Sat, Nov 7, 2009 at 8:57 AM, Anne van Kesteren <annevk@opera.com>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? >> >> >> -- >> Anne van Kesteren >> http://annevankesteren.nl/ >> >> >
Received on Saturday, 7 November 2009 18:48:37 UTC