- From: Edward Gerhold <edward.gerhold@googlemail.com>
- Date: Fri, 1 Apr 2011 18:19:46 +0200
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 changes. 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)? Edward 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*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 below) *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:* appCache.saveChangesOnIteration(true|false) Set a flag to save the changes of the event-data back to the list. event.saveChanges() 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 network. ** *New:*You can cache scripts, images, stylesheets, media to save loading time on dynamic pages 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. 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. 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*
Received on Friday, 1 April 2011 09:19:46 UTC