[webworkers] SharedWorker and ApplicationCache
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
[webworkers] SharedWorker and ApplicationCache
by Anne van Kesteren-2
::
Rate this Message:
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/ |
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Drew Wilson-3
::
Rate this Message:
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@...> 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? |
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Michael Nordman
::
Rate this Message:
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@...> 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. |
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Drew Wilson-3
::
Rate this Message:
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).
-atw On Sat, Nov 7, 2009 at 10:47 AM, Michael Nordman <michaeln@...> 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. |
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Michael Nordman
::
Rate this Message:
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.
Pages can do this: <html manifest = 'foo'> Shared workers have no such syntax. Its not up to the invoker of a page to express this association, its up to the author of the page do to so. I'd vote to do the same for shared workers. Otherwise, if we create a different means of declaring the association, a different set of algorithms have to be specified to handle it.
I can think of at least two ways for the author of the worker script to express it's manifest file. 1. Blatantly hacky, comment-based syntax // SharedWorker.applicationCache.manifest = 'foo'
2. A script-based syntax, a new attribute in the workerContext for shared workers. workerContext.applicationCache.manifest = 'foo'; // the provided value is interpretted as relative to the shared worker script url
// can only be set when initially eval'ing the script into scope (otherwise throws) // can only be set once (otherwise throws) // must be set prior to initiation of any sub-resource loads (otherwise throws)
// can be read anytime and will reflect the string value set by the caller (if any) On Sat, Nov 7, 2009 at 12:00 PM, Drew Wilson <atwilson@...> 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). |
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Alexey Proskuryakov-4
::
Rate this Message:
07.11.2009, в 10:47, Michael Nordman написал(а): > 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. Don't shared workers depend on HTML documents for network loading? I'm not sure how they can have independent caches, if they just ask a document to fetch a resource for them. - WBR, Alexey Proskuryakov |
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Drew Wilson-3
::
Rate this Message:
The specific implementation of SharedWorkers in WebKit does this currently, but that is not a feature of the spec - I have this on my todo list to resolve once I've finished the Chromium version of shared workers.
-atw
On Mon, Nov 9, 2009 at 10:09 AM, Alexey Proskuryakov <ap@...> wrote:
|
|
|
Re: [webworkers] SharedWorker and ApplicationCache
by Michael Nordman
::
Rate this Message:
Shared workers do not depend on HTML documents for resource loading. I think the webkit impl may have it cobbled together that way at the moment, but thats per-happen-stance, not per-the-spec.
Shared workers effectively establish a new top-level-browsing-context all unto themselves.
On Mon, Nov 9, 2009 at 10:09 AM, Alexey Proskuryakov <ap@...> wrote:
|
| Free embeddable forum powered by Nabble | Forum Help |
