W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Offline Web Applications status

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 23 Mar 2011 10:29:42 -0700
Message-Id: <ABA215BB-2AE8-454F-B40B-E6A8FC03DE94@jumis.com>
Cc: louis-rémi BABE <lrbabe@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-webapps-request@w3.org" <public-webapps-request@w3.org>, Adam Peller <apeller@us.ibm.com>
To: Jon Ferraiolo <jferrai@us.ibm.com>
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.


On Mar 23, 2011, at 9:42 AM, Jon Ferraiolo <jferrai@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.gif>louis-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 <lrbabe@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-request@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é

Received on Wednesday, 23 March 2011 17:30:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:17 UTC