[whatwg] Improving the Application Cache

[Edward Gerhold]

Dear Working Group,

reading it again makes it clearer. I forgot the seek function in the
document and had a type-o "increse" at .pos().
Call back soon before may, and wish you could add the things to the spec
before releasing a recommendation with.
Feel free to improve, to rewrite a little and to formulate with your own
words.  [I don´t work for any company, so there
is no copyright or business claim on, you could simply take the idea and
improve it. To all other vendors, i forbid to take
the idea and patent it instead of the whatwg/W3C, of course. Please help
improving instead of destroying the WebApp
Specification. These brackets could have been skipped, but take them
serious. You can use the idea without worrying.]

With friendly regards
Edward Gerhold

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

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
to iterate
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,
MODIFY, LISTING.

The events MUST carry the actual data, url, index number, possible id being
transmitted with.
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
the event.

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
docs.joomla.org

*Extensions to the appCache Interface*

.add(url, data) - append a new element to the list
.insert(id, 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
*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.) *
*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

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
network. *New:*You can cache scripts, images, stylesheets, media, and with
the javascript enhancement you can modify the cache and load whatever the
user desires to the cache.

You can now load, what the user desires from cache.
Arguments having the functions above and the Master File cached

The user may choose, what to cache.

You may choose, what to cache.
Security considerations

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
id

Browsers COULD save parts of the dom tree with possible id in the cache,
too.

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
done.
Other documents

*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
applicationCache.
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,
*Edward Gerhold*