Offline Web Applications status
Hello Webapps working group, I'm an intern at Mozilla Developers Engagement team and I'm currently working on promoting Offline Web Applications. My first task is to understand what did go wrong with the App Cache mechanism... ## 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. ## Can you see other reasons? ## 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. ## Two naive questions ## 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. Why isn't there any DOM API allowing a fine-grained control of the application cache? applicationCache.cache.add( URI ); applicationCache.cache.remove( URI ); Thank you in advance, Louis-Rémi Babé
Re: Offline Web Applications status
I second these comments: we have a web app over one meg in js scripts alone, and it is designed for full offline usage. AppCache has been very quirky and often difficult to debug. It adds a few steps in the distro process and can get-in-the-way of debugging changes on a rapidly developing app. That said, there have been some good improvements in UAs recently, and the Google Chrome apps distribution model works well with it. Offline Apis are still very much unstable-- as both improve, and we l see more consensus by UAs on widget manifests, there will be a lower cost to using the Apis, and more benefit for smaller projects. -Charles On Mar 23, 2011, at 9:42 AM, Jon Ferraiolo jfer...@us.ibm.com wrote: Louis-Rémi, We are working on a large-size HTML5 web application and are using appcache successfully. For a large-size webapp being delivered off of a slow network, appcache provides a huge (arguably essential) performance gain because the client doesn't have to do a server request for everything that is put into the appcache, whereas you still need to ping the server for old-style cached files. (Therefore, we are using appcache today mostly for network performance advantages versus old-style browser caching. We aren't doing offline at this point. However, we are looking at taking the next step to offline down the road.) We found it was difficult to get working on a cross-browser basis due to incomplete specs and browser quirks. I vote for improving what exists today, particularly hammering out detailed spec issues and creating a comprehensive test suite. Jon Ferraiolo, IBM graycol.giflouis-rémi BABE ---03/23/2011 08:58:09 AM---Hello Webapps working group, I'm an intern at Mozilla Developers Engagement team and I'm currently ecblank.gif From: ecblank.gif louis-rémi BABE lrb...@gmail.com ecblank.gif To: ecblank.gif public-webapps@w3.org ecblank.gif Date: ecblank.gif 03/23/2011 08:58 AM ecblank.gif Subject: ecblank.gif Offline Web Applications status ecblank.gif Sent by: ecblank.gif public-webapps-requ...@w3.org Hello Webapps working group, I'm an intern at Mozilla Developers Engagement team and I'm currently working on promoting Offline Web Applications. My first task is to understand what did go wrong with the App Cache mechanism... ## 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. ## Can you see other reasons? ## 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. ## Two naive questions ## 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. Why isn't there any DOM API allowing a fine-grained control of the application cache? applicationCache.cache.add( URI ); applicationCache.cache.remove( URI ); Thank you in advance, Louis-Rémi Babé
Re: Offline Web Applications status
Hi Louis, It's good to see some interest in the AppCache from the mozilla camp. My take on one thing that what went wrong is that the community of browser vendors stopped engaging on the topic, so I'm happy to see you posting here. You pointed out two features that have been often requested. - no way to exclude the referring document - no means to add/remove ad-hoc resources From time to time, these requests have reached the whatwg list (where the AppCache feature set is specified), but nothing much comes of them for lack of engagement. Maybe you think that the problem has to do with the specification itself. It is a static HTTP resource caching mechanism that is narrowly focused on the offline use case. The narrow focus can make it difficult to use for other use-cases (the struggle you mentioned some developers have with using it to boost performance for online apps). And more significantly, a static resource caching mechanism doesn't fully satisfy the offline use case. Consider http://myapp/view/ path_to_non_static_application_data?mode=printable. Do you think it *can* be used as an auxiliary cache mechanism... Not really, for the same reason you mentioned. How about we fix that. There's a thread on the whatwg about this topic specifically. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg24516.html Why isn't there any DOM API allowing a fine-grained control ... The ability to add/remove ad-hoc resources was removed from the feature set at an early date at least partly because the update logic would need to be considerably more complicated to handle them. Also, since then other storage apis have been specified that allow for the storage of large amounts of ad-hoc data (FileSystem). I'm aware of apps under development that are using the FileSystem for ad-hoc resources, but the ability to access/load the file system data transparently via HTTP urls is still missing. Given the other storage mechanisms that are available, I question whether adding and removing ad-hoc resources from the appcache is needed. I'm interested in seeing the AppCache evolve in the direction of closing the gap between a requested url and the data stored in IndexeDBs/FileSystem/WebSQLDatabases, being able to compute a response based on the contents of those storage repositories. Others on the chrome team have an interest in this as well. Maybe there is an evolution of the specification underway that I am not aware of. There was the DataCache draft, but that was less of an evolution than a different thing altogether. Progress on that being dropped, but there were some interesting ideas represented in that draft. http://www.w3.org/TR/2009/WD-DataCache-20091029/ -Michael 2011/3/23 louis-rémi BABE lrb...@gmail.com Hello Webapps working group, I'm an intern at Mozilla Developers Engagement team and I'm currently working on promoting Offline Web Applications. My first task is to understand what did go wrong with the App Cache mechanism... ## 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. ## Can you see other reasons? ## 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. ## Two naive questions ## 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. Why isn't there any DOM API allowing a fine-grained control of the application cache? applicationCache.cache.add( URI ); applicationCache.cache.remove( URI ); Thank you in advance, Louis-Rémi Babé
Re: Offline Web Applications status
Hi, comments inline 2011/3/24 louis-rémi BABE lrb...@gmail.com ## Maybe Web devs don't use App Cache because they don't understand what it is... ## I think most webdevs are expecting more than what is offered. It seems like a half baked solution to a potentially useful requirement. ## Can you see other reasons? ## 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. One thing that really gripes me is the fact that any changes require you to re-parse and re-download the entire cache again if any changes are detected to the manifest. I think the API needed more controls for inserting/updating/deleting single assets, handling offline XHR calls etc. What I was really hoping for was the DataCache API[1] to take off but this seems to of stalled and no longer looks like it will be developed further. I do believe plenty of developers know about the application cache but it's not exactly a sexy technology that gets huge attention. Perhaps this could be changed with some compelling use-cases. ## Two naive questions ## 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. Why isn't there any DOM API allowing a fine-grained control of the application cache? applicationCache.cache.add( URI ); applicationCache.cache.remove( URI ); See DataCache API[1] Cheers, Ryan [1] http://www.w3.org/TR/DataCache/
