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 <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é
>
>