Re: [whatwg] AppCache and SharedWorkers?

2009-03-27 Thread Alexey Proskuryakov
On 27.03.2009, at 0:16, Drew Wilson wrote: Are you suggesting that user agents may want to require explicit user permission when any application invokes ApplicationCache.update()? That might be a reasonable approach if a given user agent wants to enforce some kind of no silent update

Re: [whatwg] AppCache and SharedWorkers?

2009-03-26 Thread Alexey Proskuryakov
On 26.03.2009, at 1:01, Drew Wilson wrote: * Shared (or persistent) worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for top-level browsing contexts. (So just like navigating a window.) That may make sense for

Re: [whatwg] AppCache and SharedWorkers?

2009-03-26 Thread Drew Wilson
On Thu, Mar 26, 2009 at 3:58 AM, Alexey Proskuryakov a...@webkit.org wrote: Letting faceless background processes update themselves without user consent is not necessarily desirable. I think that they need browser UI for this, and/or associated HTML configuration pages that could (among other

Re: [whatwg] AppCache and SharedWorkers?

2009-03-26 Thread Alexey Proskuryakov
On 26.03.2009, at 19:26, Drew Wilson wrote: Letting faceless background processes update themselves without user consent is not necessarily desirable. I think that they need browser UI for this, and/or associated HTML configuration pages that could (among other duties) trigger application

Re: [whatwg] AppCache and SharedWorkers?

2009-03-26 Thread Drew Wilson
On Thu, Mar 26, 2009 at 1:19 PM, Alexey Proskuryakov a...@webkit.org wrote: But I was looking at this in terms of a model for users, not any specific security threats - if we think of persistent workers as an equivalent of native applications that need installation, then we should consider

Re: [whatwg] AppCache and SharedWorkers?

2009-03-25 Thread Michael Nordman
The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache of their parent context (frame) by default. How's this for a starting point for how these things intereract... * Dedicated worker contexts should be

Re: [whatwg] AppCache and SharedWorkers?

2009-03-25 Thread Drew Wilson
On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote: The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache of their parent context (frame) by default. How's this for a starting

Re: [whatwg] AppCache and SharedWorkers?

2009-03-25 Thread David Levin
On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson atwil...@google.com wrote: On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote: The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache

Re: [whatwg] AppCache and SharedWorkers?

2009-03-25 Thread Drew Wilson
Good point - I like the idea of nested workers, especially if the SharedWorker uses the pattern where it just passes off all incoming message ports directly to the nested worker so it doesn't have to proxy messages. It'd have to have some app-specific mechanism to get them all back when it wants

[whatwg] AppCache and SharedWorkers?

2009-03-24 Thread Drew Wilson
I'm trying to understand the ApplicationCache spec as it applies to workers, but I didn't find anything promising when I searched the archives. Is ApplicationCache intended to apply to workers? The application cache API isn't available to workers, but I'm guessing the intent is that if an