W3C home > Mailing lists > Public > public-html-comments@w3.org > July 2010

Cache Manifest (Offline Web Application)

From: David Wipperfurth <cobaltbluedw@gmail.com>
Date: Wed, 14 Jul 2010 12:47:47 -0500
Message-ID: <AANLkTinBZ1SPe0c839oaEhiTaLmcDbSUl9DLCisqamXH@mail.gmail.com>
To: "public-html-comments@w3.org" <public-html-comments@w3.org>
Hello,
     I'm a web app developer whom has tried working with the cache manifest
on a larger-end web platform, and I have three concerns that I would hope to
get addressed.  Hopefully I'm sending this e-mail to the right place...
     The first, it appears there are only two javascript hooks for
manipulating the cache: 'Update' and 'SwapCache'.  While it's not clear from
the documentation, I assume 'update' merely loads-up a new cache, while
'SwapCache' tells the browser to use that new cache.  My main concern is
actually the lack of functionality.  I would like to see ways of
manipulating the cache, changing the manifest file that the browser is using
for the cache, removing the cache all together, changing the cache of
another page under the same domain, etc.  Web platforms will be forced to be
quite convoluted if all caching mechanisms have to be handled on the server
side, especially, when the whole point of a cache manifest is that the
browser is going to limit it's interaction with the server to begin with.
     The second, a fairly substantial problem, is that as far as I've been
able to discern, the html page that the manifest attribute is attached to
MUST be cached.  Even if you add that html page to the network list, it is
unclear as to the expected behavior in that scenario and browsers are likely
to still cache the html.  This is a major restriction for the cache manifest
functionality, because there are certainly many cases where many things on
the page SHOULD be cached, but the html document it's self SHOULD NOT.
 Since the cache manifest must be attached to the root html, there is no way
to express what things should be cached if you don't want the root html
cached.
     It would be preferable to either not assume the html page is a master
resource, or invent a manifest mechanism to allow the page to be listed as
dynamic content.  I understand that this would slightly increase the amount
of work a browser would have to do to properly load an offline page, but in
general even if no one ever wanted to have dynamic html with cached images,
styles, and javascript, it would still be a bad idea to force the page that
tells you whether it should be cached or not, to be cached.  If the server
were to change it's mind about wanting that page to be cached, the browser
would never know. (That last bit is more of an anecdote, but still...)
     Finally, a fairly minor concern, but I find it a break-down of
standards that the manifest attribute would be attached to the html tag and
not it's own meta tag(or other such name/value pair tag) in the header.
Sincerely,

David Wipperfurth
Received on Wednesday, 14 July 2010 23:05:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:04 GMT