[whatwg] Improvement of the Application Cache

[Michael Nordman]

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:

> Hello,
>
> i would like to suggest an improvement for the Offline Web applications.
>
> Problem:
> 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,
> nor
> 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
> update
> 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
> think
> 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.
>
> Rules:
> 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.
>
> Javascript:
> 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
> file.
> The second function would be *applicationCache.updateFile(url)*, which
> could
> 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
> with
> the filenames and
> parameters.
>
> [(*) I could let the user decide wether he wants to download my mp3 files
> to
> the appcache or not,
> and fulfill the wish with the javascript functions. Maybe he´s got no bytes
> left or wants only the
> lyrics.]
>
> Conclusion:
> 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
> application.
>
> Question:
> 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
> cms
> 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
> addition
> to handle all these dynamic systems, too.
>
> Edward Gerhold
>