W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Improving the Application Cache

From: Edward Gerhold <edward.gerhold@googlemail.com>
Date: Fri, 1 Apr 2011 17:00:20 +0200
Message-ID: <AANLkTik_TshAx3kR756fdSZQKU_RUxrrcadP7xwOk033@mail.gmail.com>
Hello Working Group,

you can update your cache, if you have clicked the document already.
http://linux-swt.de/tools/appCache/index.html
I wanted to store the note public and resistent for a while, until the HTML
Recommendation Track is finished.
Here is an already enhanced description for the requirements for the fired
events, to let you add data there, too.

Of course this want to leave the cache easy and simple, like all HTML5
components are, but to get the most out of it by adding
functions for caching any file the user or the programmer wants. So a
content management system could grow the
cache on demand.

The other thing is the simple whitelisting of the master file, that scripts,
images and sheets could
come from the local disk and only the new document is fetched over the
network. To reduce a lot of loading times of
images, scripts, styles, media, of course.

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 nonimplementation.
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 increse pointer
.end() - end pointer
.list() - increase pointer
.reverse() - decrease pointer

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 FileAPIWith 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*
Received on Friday, 1 April 2011 08:00:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT