[TYPO3-ect] Challange: design and implementation of advanced caching

[Bernd Wilke]

On Sun, 08 Jul 2007 02:08:13 +0200, Elmar Hinz wrote
with subject "[TYPO3-ect] Challange: design and implementation of advanced
caching":

> Hi,
> 
> today USER objects are cached as part of the whole page, while USER_INT are
> not cached at all. Something in between could bring new features for TYPO3.
> Think of something like news of google. Each news element is cached. The
> personalized page is dynamically combined of the cached elements. The
> cached elements themself can be updated in defined intervals. Instead of
> caching whole pages, caching can be modularized.
> 
> USER_INT are exectud in a second phase after the page has been rendered and
> cached (the marker trick). I am thinking of a cache for objects within this
> second phase. 
> 
> We want people for the following steps:
> 
> a) You have a vision of an advanced object based caching system. You
> contribute a conception how it looks like and how it should be implemented. 

some time ago I thought about caching and this idea came up:
I don't know if it realy will speed up things or how it can be implemented.

A page can be seen as a hierarchy of elements which include each other
(i.e. DOM)
for each element you know on which data it depends and how long this may be
valid. either you can transfer this info to higher elements 
or you can store either the inner or the outer data depending which element
lasts longer, replacing a marker with the dynamic element to get the final
element. (like it is done now in typo3 with userint)

the dependencies may vary in categories like this:
- static (will never change until edit)
- depends on one single record /variable
- depends on a group of records (category)
- depends on a database-table
- dynamic (will change on every call)

example:
a phonebook with listview and singleview:
the HTML of the singleview depends on a record identified by the ID of each
record. as long as there are no changes these data can be stored after the
first computation.
adding one new phonenumber does not change the display of the other
records, but change the listview. in the same way a change in one record
will affect only the display of this record and the listview.


if each element can store the datetime of the original data you know when
to rebuild an element. or you know when to delete computed data because
your original data changed.

advantage of this concept: you can store data until a new compution is
really neccessary. no compution on guessing (once a day or every time)

> b) You implement this within lib.
> 
> c) You design a TS API, so that it can be set up and used also with TS.
> 
> d) You implement it as TS object.
> 
> Anybody?
> 
> Regards
> 
> Elmar


Bernd
-- 
http://www.pi-phi.de/t3v4/cheatsheet.html