[whatwg] Improvement of the Application Cache
pecoraro at apple.com
Thu Mar 3 19:07:36 PST 2011
Sounds related to "Programmable HTTP Caching and Serving" (formerly titled DataCache API):
[[[ This document defines APIs for off-line serving of requests to
HTTP resources using static and dynamic responses. It extends
the function of application caches defined in HTML5. ]]]
On Mar 3, 2011, at 1:50 PM, Michael Nordman wrote:
> Sounds like there are at least two feature requests here...
> 1) Some way of not adding the 'master' entry to the cache. This is a common
> feature request, there's another thread about it specificially titled
> "Application Cache for on-line sites".
> 2) The ability to add(), remove(), and enumerate() individual urls in the
> appcache. Long ago, there were interfaces on the appcache drawing board to
> allow that. They got removed for a variety of reasons including "to start
> simpler". A couple of years later, it may make sense to revisit these kind
> of features, although there is another repository also capable of storing
> ad-hoc collection of resources now (FileSystem), so i'm not sure this
> feature really needs to be in the appcache.
> @Hixie... any idea when the appcache feature set will be up for a growth
> spurt? I think there's an appetite for another round of features in the
> offline app developers that i communicate with. There's been some recent
> interest here in pursuing a means of programatically producing a response
> instead of just returning static content.
> On Wed, Mar 2, 2011 at 7:40 AM, Edward Gerhold <
> edward.gerhold at googlemail.com> wrote:
>> i would like to suggest an improvement for the Offline Web applications.
>> I´ve found out, that i can not Cache my Joomla! Content Management System.
>> Of course i´ve read and heard about, that the application cache is for
>> static pages.
>> But with a little change to the spec and the implementations, it would be
>> possible to cache
>> more than static pages.
>> I would like to cache my Joomla! system. To put the scripts, css and images
>> into the cache.
>> I would like to add the appcache manifest to the index.php file of the
>> Joomla Template.
>> What happens is, that the index.php is cached once and not updated again. I
>> can not view
>> new articles. The problem is, that i can neither update the Master File,
>> whitelist it.
>> And this is, what my request or suggestion is about. I would like to
>> whitelist the Master
>> file, where the appcache manifest is installed in. Or i would like to
>> this file, or any
>> file else, i would like to update, on demand.
>> If there is any possibility, to do that already, please tell me. But i
>> that is not the case.
>> Caching the CMS by making it possible to update or to whitelist certain
>> files, the always
>> dynamic frontpage or /index.php, would be the hammer to nail the board on
>> the storage.
>> The things, which should be considered are: *To allow to fetch the Master
>> file, e.g. index.php*
>> *in Joomla! over the NETWORK,* while any other file in the manifest get´s
>> fetched or cached like
>> before. Which is the most important for me, to get Joomla! into the cache.
>> For the script i would like to add *applicationCache.updateMaster()*, which
>> forces the browser
>> to fetch the file again. I think, this is impossible today, to update
>> exactly this file. For the function,
>> i could add a button to my page, to let the user choose to update the
>> The second function would be *applicationCache.updateFile(url)*, which
>> be triggered by
>> a button and script, too. I could let the user update certain articles.
>> With that i would like to suggest* applicationCache.addToCache(url)* to add
>> files manually or
>> programmatic, which can not be determined by the manifest. Urls like new
>> articles (*), i would
>> like to read offline. I would like to add them to the cache, if the link
>> appears, maybe on the
>> frontpage. I would have to add the manifest to the CMS anyways, so i could
>> add a few
>> more functions to the page, of course. *
>> applicationCache.removeFromCache(url)* should
>> be obvious and helpful with the other functions.
>> Good would be, to be able to iterate through the list of cached objects and
>> even the manifest,
>> with the update, add, remove functions, it would be very useful to work
>> the filenames and
>> [(*) I could let the user decide wether he wants to download my mp3 files
>> the appcache or not,
>> left or wants only the
>> The application cache is very powerful. But it is very disappointing, that
>> it is only useful for static
>> pages. With a little improvement to the Offline Web applications chapter,
>> and of course to the browsers,
>> it would be possible to cache any Content Manager or dynamic page. And that
>> would let the appcache
>> become one of the most powerful things in the world.
>> I could read my Joomla! offline, could update the cached files, if i want
>> to, on a click or if the cache expires.
>> I could let the half of the CMS load from the cache. But for that, the
>> index.php, where the manifest is, has to
>> be updateable. Correct me, if i am wrong. But this is not possible today,
>> the master file can not be influenced.
>> And there is no expiration or a possibility to update or manipulate the
>> cache and even no way to find out which
>> files are cached, what would let me/us have control over the Offline Web
>> Could this become changed in the appcache section? You would make the
>> appcache so powerful, that any
>> kind of software could be used offline. I would like to know, how far this
>> could become true or how much
>> that is of interest for you. I have not followed this mailing list until
>> half an hour ago. So i do not know. I learned
>> what is missing and working by practice and testing the appcache with my
>> and my static hip-hop pages.
>> Oh, i forgot one thing: Wildcards in the manifest. And I think, directories
>> belong into the CACHE section, i got
>> an error on any directory there, i had to state the whole filename. You
>> should abbreviate that. But that is not
>> so important against that what i wrote down in this message above. Anyways,
>> this completes my wishlist.
>> Correct me, if i am wrong. But please take this message serious. I hope
>> other people have submitted this already,
>> that you could compare or get that underlined, before that spec goes into
>> last call and becomes standard. The
>> appcache could become very very and extremly powerful with a little
>> to handle all these dynamic systems, too.
>> Edward Gerhold
More information about the whatwg