- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 10 Jun 2011 23:30:40 +0000 (UTC)
- To: louis-rémi BABE <lrbabe@gmail.com>
- cc: public-webapps@w3.org
- Message-ID: <Pine.LNX.4.64.1106102326350.19153@ps20323.dreamhostps.com>
On Wed, 23 Mar 2011, louis-rémi BABE wrote: > > ## Maybe Web devs don't use App Cache because they don't understand > what it is... ## > > The possibility of using Webapps offline has a great potential but its > adoption by developers didn't reach our expectations. We asked Web > developers some time ago what were their feelings regarding application > cache (see http://hacks.mozilla.org/2010/05/revitalizing-caching/ ) and > it appeared that the name was misleading, as they expected it to be more > of an auxiliary cache than an offline mechanism. You can find evidences > of this confusion on StackOverflow, where some people struggle to use > the application cache as a mean to boost performances of their Websites. Interesting. I'd be happy to rename the concepts in the spec to "offline application store" or some such, but it may be too late to rename the APIs, so this might be a lost cause. > Before going back to developers or writing yet another App Cache > documentation, I wanted to have *your* feelings about this mechanism. > You might have a different impression about its adoption and be aware of > successful real-world use-cases. You might have asked developers > yourself and received a different feedback. Maybe you feel that Web > advocates are not doing a good enough job at documenting this feature, > producing demos and clarifying its nature. Maybe you think that the > problem has to do with the specification itself. Maybe there is an > evolution of the specification underway that I am not aware of. The main reason I've seen is that most people simply don't care about making their applications available offline. > After reading a large amount of documentation, I have to admit that I am > myself confused about app cache: Do you think it *can* be used as an > auxiliary cache mechanism, and what would be the limitations? The main > problem I see is that there is no way to white-list the referring > document (e.g. index.html). Currently, I would advocate *against* using > it as an auxiliary cache. I'm not sure what you mean by "auxiliary cache". Appcache only provides one feature that the regular HTTP cache doesn't: the ability to guarantee that a particular set of files are available offline when the UA cannot hit the network. Beyond that, the main HTTP cache can do everything appcache can, as far as I can tell. > Why isn't there any DOM API allowing a fine-grained control of the > application cache? applicationCache.cache.add( URI ); > applicationCache.cache.remove( URI ); We might add that in due course. I am mainly waiting for appcache to gain more widespread implementation support first. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 10 June 2011 23:31:04 UTC