Re: Offline Web Applications status

The main requirement for a "webapp" (or a website) to use App Cache,
is AJAX capability.
Without AJAX, the webapp is just like offline STATIC application
(which is boring).
So, in order to use App Cache, developers must re-design their
websites so that it is AJAX enabled (which requires too much work).

Now, if only there is a way to avoid the main page (index.html) to be
cached, then AJAX is NOT REQUIRED!
The developers can just list down the manifest as it is, but the
index.html will always be updated.
So, no need AJAX to deliver "what's new" on the page.
Note that the webapp can still be used offline (the old index.html is
served if the user is offline).
The App Cache is used purely to cache the "most likely immutable"
resources (images, javascripts, csss, flashes, etc..)
And with this, the developers DON'T need to change anything on their
working website, except adding manifest link!

With this, the whole web will be far far far faster (imagine how many
jQuery users and jQuery UI and other libraries can be cached!).

So, if you really want the App Cache to be used virally, the browser
vendors better start giving option to EXCLUDE the main page to be
cached.

So far I haven't see why this option can't be done?

Felix Halim


2011/3/23 louis-rémi BABE <lrbabe@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é
>
>

Received on Friday, 1 April 2011 09:50:10 UTC