[TYPO3-dev] t3lib_cache

[Ernesto Baschny [cron IT]]

ries van Twisk wrote: on 18.01.2008 17:58:

>> Yes, but which? A list view showing the 5 "latest" news in category ABC.
>> How will a single record change affect that cache? What about a *new*
>> news record? Will it appear on that page? Depends on its timestamp and
>> on the category it is in etc. Maybe a record is updated, it was on
>> category XY, now it is also on category ABC. Only the extension itself
>> knows where this record might appear. This is what I was trying to
>> explain, why it is not so simple for TYPO3 core to know what caches to
>> clean on a simple record changes (or on expiration of endtime).
> 
> The extension is responsible to register each record (list or single) that
> will appear on a page. So this goes for list aswell as for single (or 
> any other 'view').
> The extension should know..

Hm, I guess this discussion is going in circles, as you are not really 
trying to comprehend what I am trying to explain. :)

>> Your proposed table
>> is exactly what I was trying to propose, only that your solution is
>> based around the assumption that rendered pages are just dependant on
>> the status of specific database records and my proposition was based on
>> the assumption that it is up to the extension to "know" which records
>> affect what parts of the cache.
> 
> I feel that page cache clearing is a core problem (and this is where we 
> differ), not a extension problem.

But your solution doesn't really solves it, does it? It gives the 
impression of solving something that isn't solved completely. This will 
only make people re-start using USER_INT or "no_cache" because they 
don't get it why the "list view" on the home page isn't updated when a 
record is changed.

>> Try to go through my simple examples above and try to see what this
>> means in your proposed solution.
> 
> We all want the same and that is an API for cache handling,
> I just don't like an API that an extension can (mis) use for cache clearing
> functions which is similar as the no_cache function already available.

So if you have a solution at hand for the problem, please share. The 
"record based" solution is not a complete solution in my eyes for the 
reasons I already explained. It only solves a bunch of very common 
situations.

Cheers,
Ernesto