[TYPO3-dev] set_no_cache is bad. What's next?

Wed Apr 4 01:54:14 CEST 2007

On Mon, 02 Apr 2007 17:55:56 -0500, R. van Twisk wrote
with subject "Re: [TYPO3-dev] set_no_cache is bad. What's next?":

> 
> Something that can understand the data structure better.
> For example
> 
> let's say we store data in a hierarchy:
> 
> a-
> --1
> --2
> --3
> --b
> ----4
> ----5
> ----6
> c
> --7
> --8
> --9
> ----d
> ----e
> ----f
> g
> --10
> --11
> --12
> 
> You can see the above as a forum (a, b, c) with different
> posts, or news with categories... It doesn't really matter.
> 
> Now when a cache needs to be cleared I would like to tell
> the caching API 'clear cache of tree c', or 'clear cache of tree b'
> or 'clear cache of item 10'.
> 
> That way we can instruct the caching mechanism to only clear
> parts of the cache, instead of simply the whole structure.
> 
> Above, I am not talking about the page tree, or the cache of pages,
> above I am talking about a API where extensions can store data
> in a hierarchical way, and teh extension can decide what parts
> to purge. Or using auto purge parameters like:
> - Clear (part of the) cache at some time
> - Clear (part of the) cache at some event..
> - Clear (part of the) cache  per instruction made by the extension
> 
> A simple 'make hash and retrieve' data system will not work well
> for extensions for several reasons outlined in other parts of the thread,
> or the danger of flooding the cache when wrongly used (just look
> in the mailing list for 'Help my DB is 5Gb big', or similar posts.
> 
that reminds me:

my first imagination of a cms for websites:
it should build up data like the DOM-tree and then render it to clean
XHTML.

if i notice the dependencies of each node I can decide which nodes have to
build again.

let's have an example:
(the DOM tree can be represented as a XML-structure)

<page>
  <header>
    <logo>
      image
    </logo>
    <mainmenu>
      pagelink1
      pagelink2
      pagelink3
    </mainmenu>
    bannerimage
  </header>
  <body>
    <forum>
      <overview>
        threadlink1
        threadlink2
        threadlink3
      </overview>
      <singleview>
        posting1
        posting2
      </singleview>
    </forum<
  </body>
  <footer>
    imprintlink
    contaktlink
  </footer>
</page>

whith every level I store the information about caching and on a change I
know which part of the tree must be rebuild:

there was a answer to posting2:
+<page>
-  <header>
-    <logo>
-      image
-    </logo>
-    <mainmenu>
-      pagelink1
-      pagelink2
-      pagelink3
-    </mainmenu>
-    bannerimage
-  </header>
+  <body>
+    <forum>
-      <overview>
-        threadlink1
-        threadlink2
-        threadlink3
-      </overview>
+      <singleview>
-        posting1
-        posting2
+        posting3
+      </singleview>
+    </forum<
+  </body>
-  <footer>
-    imprintlink
-    contaktlink
-  </footer>
+</page>

so it belongs to <singleview> this has to be rebuild (only the <singleview>
which contains the new posting. It depends on the posting records, so its
cached data is represented by those ids. adding a new id makes the cache
invalid

so <singleview> has rebuild, the containing <forum> has to be rebuild, it
can gather the cached data from <overview> and the new <singleview>

next level:
<body> has to be rebuild, because it contains <forum> which was rebuild

now the page has to be rebuild, whith the cached data from <header> and
<footer> and the new data from <body>

I don't know the exact datastructure, is it possible?
any negotiations? any errors?

Bernd
-- 
http://www.bernd-wilke.net