[whatwg] Improvement of the Application Cache

2011/3/3 Michael Nordman <michaeln at google.com>

> 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".
>

You got it right and i find it good, that the people have this topic already
discussed. Had expected that, but i?m glad, that someone tells me, that.
Some way of "not" adding the master file to the cache. Yes, or have the
master entry added, but letting it be threatened as an updateable file. I
would need to either update the file on demand, or whitelist and get it over
the network.
That would make add(), remove() and enumerate() neccessary for me. Not
adding it would be a possibility to pass that static
index page, too.


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

Wouldn?t it be easier for the programmers, to have both, static and dynamic
pages together in one application cache? It is a
nice advice, that i can use the FileSystem for this, and i will check it
out, because it is already existing and almost usable. But
i would find it better, to be able to use the appcache for both. The
functions would let the cache component look better and
improve the functionality.
Saving and loading the pages from the disk is ok for me, i think i got the
point now, but i have to argue again, that i would
see the cache completed together with these functions, not without. [Ok, but
using the filesystem...ok, i could loop here
and argue myself death for both. I?ll be for extending the cache.]

>
>
@Joseph: I had printed that document a few weeks ago and read it in the
subway, that was before testing the appcache,
and i?d read that it?s using window.appCache, but hadn?t seen, that this is
almost doing, what i request here. Thanks for
the hint, i?m going to take it with me tomorrow to look it through again.
That is not implemented anywhere, that i can use
it already, or?
If that feature is doing, what i want, add(), remove(), enumerate() AND
update the Master or update any file, or to let me
store my Joomla! (or any other), i would be for it.
[Today i don?t know what this document is doing.]

If i couldn?t update the master or any file or not add and remove any file,
to have programmatic control over the files in the cache
i would be voting for adding these features [to the cache spec]. You are the
experts, i thrust you, that i have at last one option
later, to do all that [Here the argumentation for the filesystem seems to be
good for me, i could save and load my docs on demand.
But having no method to update the master file still brings me into trouble,
if i want to combine these two, cache and filesys.]

I think, i?ll write it again to say it again clearly: My favourite would be
to extend the app-cache spec with the remaining features,
rather than working around with the other apis. For readability in the
documentations, less thinking about code, and of course
completeness of the application cache system.

Edward

Received on Sunday, 6 March 2011 12:16:28 UTC