[whatwg] Improvement of the Application Cache

Yes, it does, in particular the add(), remove(), and enumerate() parts. That
spec is in the act of being dropped by the webapps working group. I think if
we want to see features along those lines, we should see them in the context
of the HTML5 AppCache.

On Thu, Mar 3, 2011 at 7:07 PM, Joseph Pecoraro <pecoraro at apple.com> wrote:

> Sounds related to "Programmable HTTP Caching and Serving" (formerly titled
> DataCache API):
> http://dev.w3.org/2006/webapi/DataCache/
>
>   [[[ 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. ]]]
>
> - Joe
>
>
> 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:
>
> 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
>
>
>
>

Received on Friday, 4 March 2011 11:59:26 UTC