Re: [whatwg] Latest proposal for offline web app API

On Fri, 21 Sep 2007, Aaron Boodman wrote:
> > 
> >  * If you're offline, and any of the caches have fallback pages
> >    associated with a pattern that matches the URI of the resource
> >    being fetched, then:
> 
> Not "offline", but the request failed right? This shouldn't rely on 
> having the browser literally be disconnected.

Right, the spec basically defines that as failed DNS, 4xx, 5xx, or 
similar.

And for the manifest, "offline" even means "doesn't have 
text/cache-manifest MIME type", which we need to ensure that you don't 
screw up everything when in a captive portal. Note that the opportunistic 
caching namespaces don't handle a captive portal well -- they would end up 
caching the portal and not letting it get uncached until the next update. 
That's actually quite bad. Maybe we need a way to get around this? Should 
it not cache things that redirect off the domain or something? (Captive 
portals usually do their work by redirecting.)


> > Then, the document must be loaded. If, during load, an application="" 
> > attribute is found, then, if a cache with that manifest URI already 
> > exists, then, add the resource URI to that cache, and associate the 
> > browsing context with that cache. If no cache exists for that manifest 
> > URI, then create a cache for that manifest URI, and add the resource 
> > URI to that cache. (XXX How do we handle <?xml-stylesheet?> PIs? XXX)
> 
> I didn't understand this bit. I thought that if you had found an 
> application cache during the previous steps, you load the resource from 
> that cache and then start the update in the background. I don't get 
> what's going on here with checking the document for the application 
> attribute and then adding it to the cache.

Does the current spec answer your question or are you still confused?


> >  * Swap in the newest cache without a reload.
> 
> This implies that the application can decide when to swap the new cache 
> in, but I don't think that's true. For example, if a user decides to 
> open a new window with the application, then the cache will get swapped 
> in right? Even though none of the apps chose that.

Each browsing context has individual control over which version of the 
cache it's using. There can in fact be multiple different versions of the 
cache at any one time.


On Sat, 22 Sep 2007, Křištof Želechovski wrote:
>
> Why not "text/xml+cache-manifest"?
> (Admittedly I can see a problem with this: '+' means addition but '-' does
> not mean subtraction so it looks quite funny).

Well, it's not XML, for one...


On Mon, 24 Sep 2007, Robert O'Callahan wrote:
> >
> > * Add a resource to the cache. The resource persists (it's a
> >   permanent addition to the manifest.)
> 
> So if an update retrieves a new version of the manifest from the server, 
> what will happen to dynamically added resources?

They get propagated.


> Nondeterminism about which cache might be used to serve a given URI 
> seems highly undesirable to me. This could easily lead to 
> interoperability problems.

Can you give an example of a scenario in which problems would occur? I'm 
not sure I really can see the problem.


On Sun, 23 Sep 2007, Maciej Stachowiak wrote:
> 
> I believe the only nondeterminism is for top-level resources that appear 
> in more than one cache. An alternate possibility is to require that they 
> be served from the most recently updated cache. However, the 
> counter-argument might be that operations like "open image in new 
> window" should pass the cache along to the resulting new top-level 
> browsing context. Perhaps it should be required that the newest 
> available offline cache is used, except optionally in such cases. I'm 
> not sure how that could be well-defined however.

Indeed.

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