W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] Caching offline Web applications

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 24 Dec 2008 02:13:35 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0812240128520.24109@hixie.dreamhostps.com>
On Tue, 18 Nov 2008, Michael Nordman wrote:
> > > 
> > > 4) Why require text/cache-manifest mimetype?
> > >
> > > Presents a small hurdle to get over. What is being accomplished with 
> > > this requirement?
> >
> > This is actually just a restatement of HTTP's requirements. If you 
> > want the Content-Type to be ignored, please contact the HTTP working 
> > group and have them change the requirements for handling HTTP 
> > Content-Type headers. :-)
> 
> Could we specify text/plain (or text/*) as the valid content type so a 
> developer doesn't need access to the server infrastructure to get UAs to 
> accept her/his text resource as a manifest file?

I would be fine with that, but it would be a violation of HTTP semantics. 
If you can get the HTTP working group to change their requirements, I'd be 
very happy to change the spec here.


> * Its not clear that resources add()ed around update initiation time 
> will make their way to a new cache that results from the update. I think 
> the intent is that add()ed resources will show up in the new cache 
> regardless of when add() is initiated or completed, but this isn't 
> clear.

Clarified.


> * Is it an error to initiate the add() of a resource to a cache after it 
> has become obsolete?

No, but it won't do the application much good.


> * Should there be onaddsuccess / onadderror events that fires when 
> add(s) complete?

A network fetch can take an indeterminate amount of time, so it's not 
clear to me that this would be that useful. There's hasItem() method if 
the application needs to know if the add has succeeded yet. add() is 
idempotent, too, so if the app really wants to make sure something is in 
the cache it could just keep trying to add it or something...


> * Pseudo code omission (i think):  I don't see where the pseudo code 
> inserts new master entries or informs already running update of newly 
> discovered master entry.

It's done in the application cache selection algorithm, and then as part 
of step 1 of the application cache update process. I've hyperlinked one 
use of the word "master" that wasn't hyperlinked before, which might help. 
I agree that this text isn't uber-clear.


> * Towards the end of an update, 'candidates' are not associated with the 
> new cache in the upgrade attempt case. The differences between the cache 
> attempt vs upgrade attempt seems odd.

In the upgrade case, they're already associated.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 23 December 2008 18:13:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC