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
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
Sorry folks, it was a long meeting for me so this was delayed.
The draft minutes are included at
http://www.w3.org/2009/11/02-webapps-minutes.html starting from the WebIDL
section - http://www.w3.org/2009/11/02-webapps-minutes.html#item06
We discussed
WebIDL
We're going to update it to
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any intended restrictions on caching of objects returned by
queries and gets with WebSimpleDB? For example (using the address book
example in the spec):
|database = window.openDatabase('AddressBook', '1', 'Address Book', true);
