- From: Edward Gerhold <edward.gerhold@googlemail.com>
- Date: Tue, 19 Apr 2011 21:14:59 +0200
Dear Group and Readers, writing a subsection "Whitelisting the master entry", 6.6.3.4 would allow me to remove any "The master file is always cached"-like clauses, i think i?ve read before. The browser programmers will have followed these steps and so originally the master file had always been cached. Logically if you think about it. The other subsection on a higher level is "The application cache lists", a chapter _about the container_ keeping the media. I dunno if there is one list, or three lists, for each section one, or what is read by the browser programmers, when they wrote the cache. For that, i think i have to pull out another ace. I am gonna look at the browser source codes, to see, what kind of structures they used for the application cache entries and lists. There i?ll learn, how they connected the javascript commands to the class operations in the c++ code. I think i?ll start with chrome, because i have a recent copy of chromiums sources. With the knowledge from that side, i should could create a good explanation of what to add to the containers and how to connect the new operations for the javascript api. The add to remove, iterator functions and the cool new events which allow to code plugins changing the cache contents. The stuff i?ve written about. That makes sense, a container section, or? I won?t change the existing thing in any way, but extend the programmed container with the function. Like in my first mail, but in this form in the specification document. I think the lists for the cache are explained, but how the browsers implemented it, i have to look after. The new chapter would exactly speak about the container and how the media is dynamically managed by the web application. There are attributes (let ...) and functions (step by step). I still am not shure if i will renumber the last sections or whatever. Sorry for my lameness to take a few more days. Until then With friendly regards Edward Gerhold
Received on Tuesday, 19 April 2011 12:14:59 UTC