[whatwg] Enhancements to the Application Cache (Reminder)
edward.gerhold at googlemail.com
Fri Apr 1 09:19:46 PDT 2011
Dear Glenn, i don´t want to spam the list.
What is happening is, that i allow myself to post the file again, then i´ll
be quiet. I hope that the things i write are receiving the working group and
the people thinking about HTML5 and that they´ll wake up. I have improved
the words once again. If you have read the first version, the second and the
third, or fourth and the fifth or what this is, you will see, that i have
removed some "bugs" and removed some type-o´s, being sure, that my english
is currently bad, but also being sure, that programmers can 100% read this.
If you have read it, you may have noticed, that the get operation is missing
to get an object to show it. And i have made another statement about the
events, which should be fired on enumeration, too and to let the programmer
have the control, to modify and write the objects back using the iteration,
too. I think to let the inventors of HTML5 know clearly, what i and many
others need, i post it again.
I think i am through with almost all requests we have. What else you can do
is listed under "Other documents", but i would like to have the cache
complete. Please accept posting the file once again. I have made important
I would rather like to know, what is your oppinion about making these
changes to the cache, than that i´m spamming the list! I don´t do so. I´ll
keep quiet for the rest of the day and the time. Do you have an opinion
about making the cache ready for storing data instead of my static page with
my images (almost forever)?
Application CacheEnhancements to the Caching FunctionsStoring dynamic,
generated and like before, static Data in the Cache*Abstract*
With this document i want to persuade the whatwg and the W3C to enhance the
application cache of HTML5, before the standard is seeming to be ready, and
to prevent to suggest it for HTML6, because of a non-implementation.
The appCache is not ready for storing dynamic data. This could be done by
the user by simply pressing a "cache this" button or a link or some other
function in a script.
There MUST be the possibility to add urls to the cache.
There MUST be the possibility to remove, modify urls in the cache and
through, enumerate the cache.
*Trivial passing of event data for progress display etc*
The functions SHOULD or MUST fire a function-named event, e.g. ADD, REMOVE,
The events MUST carry the actual data, url, index number, possible id being
Change data in the event (Scenarios)
*Scenario:* Like get the data for cache, add a "cached" string and the "x"
(checked) image to the sidebar. To the document itself. Any other program
reading this directory, would note that the program writing cached and "x"
has cached it.
*Other scenario resulting from:* Add brandings to the cached files.
Suggestion: Event data MUST be changeable! The data is passed to the event.
Then the programmer may modify the cache object. Then the event data is
saved. So it could be modified a last time before add, edit, removed through
In the content manager Joomla! the data can be changed in the plugin-event
before the data is displayed. And the are events after the display. See
Extensions to the appCache Interface*writing functions*
.add(url, data) - append a new element to the list
.insert(id | url, data) - move from pos all elements from the last on
to the insertion pos downwards (add last element as new)
.remove(id | url) - copy the next element to the pos, continue and
remove the last from the list
.modify(id | url, data) - change the element data in the list*reading functions*
.get(id | url) - gets an object from the cache. DoesnÂ´t store a new object.
[Maybe get with more than one id and url parameter results in an array
of objects? ]
*These operations fire events, the data is referenced by the event object,
it can be modified in the event again, then the (maybe) modified is added,
inserted, modified.* E.g. modify: you can modify a page and then
modify it, while modifying the
modified page, again by the MODIFY event. This is useful.
The get event fires the event where data could be modified, too. You could
let the programm add data before displaying the object, without saving
it. You could save it explicitly with eventObject.saveChanges() (see
*DonÂ´t forget to save to disk*
*Enumeration of the Cache
returns active element seeked to
with index number, url and possibly id and data*
.begin() - start pointer
.pos() - doesnt increase pointer
.end() - end pointer
.list() - increase pointer
.reverse() - decrease pointer
.seek() - set pointer to a pos
They should fire the events too. The programmer can choose to display the
event data and even to modify all the enumerated objects.
*Saving event data even on enumeration:*
Set a flag to save the changes of the event-data back to the list.
Save a single cache object from within the event back to the list.
I donÂ´t know WebIDL, hope you can read it as, and like, WebIDL.
Removing the Master File from the Cache
Explicitly remove like above and the cache will behave to cache it again.
Explicitly add the file to the manifest NETWORK: index.php (Variant 1,
whitelist), NETWORK: MASTER (Variant 2, whitelist parser), or CACHE MANIFEST
NOMASTER (first line).
Not caching the master file, means loading the file everytime from the
*New:*You can cache scripts, images, stylesheets, media to save loading time
on dynamic pages
the user desires to the cache.
You can now load, what the user desires from cache. The .get() function
makes it easy to retrieve a single object from the cache.
Arguments having the functions above and the Master File cached
The user may choose, what to cache.
You may choose, what to cache.
Malicious Pages writing malicious caches?
IsnÂ´t there detection for most of? Something like this is needed and the
same-/cross-origin policy already used.
I write down no new suggestions for changes to the security in this
document. It is only for the new (or remaining) Cache Functions (for HTML5).
Appendix - Caching DOM tree branches with url identifiers, and root element
Browsers COULD save parts of the dom tree with possible id in the cache,
I hope this could become discussed again. I hope the features could be set
onto the vendors to do list, by the HTML5 specification, before HTML5 is
*Programmable HTTP Caching & Serving*, with an immediate function and a
local server and the applicationCache2 Interfaces.
The enhancements suggested here are easier to learn and use. By the use of
applicationCache2 in the other document, the functions here could stay in
A workaround with the *FileAPI*
With the FileAPI you can save files, but it is not the cache. You have to
insert FileAPI functions to the Master and the other pages as well as button
or links calling the functions, similar to the on-demand-caching buttons in
my verbal examples, handling the page creation, storing and loading.
Reason for this document.
Please let my cache my content managers, as far as i prepare the urls to be
used by my script for caching, on the users demands.
With friendly regards,
More information about the whatwg