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

[R. van Twisk]

Franz Holzinger wrote:
> Hello Ries,
>
>   
>> nice explanation, and I go a bit OT and I will go to the extreme.
>> The above method also means that if you have 50.000 posts,
>> you will loose the complete cache for all posts, just because
>> somebody else added a single other post.....
>>
>> I think I am right.... am I???
>>     
> This would be the case only if all the 50 000 posts would be shown on
> the same page. This would not make sense however. Only the 50 000 topics
> of the posts will be shown. And this list must be regenerated with every
> new post.
>
>   
Isn't this the case with most extensions?
I don't know tt_board at all, bit I have seen a lot of extensions 
heaving a different modus for different
actions. Kickstarter creates by default single and list all on the 
single page.

My extensions often doe most actions on the same page as well. it's just 
easy.
That means flushing the cache of a single page means that all info is lost.






>> It just means that if a typo3 installation is mostly community driven.
>> Which means only a couple of pages but lots of forums and dynamic
>> content from single plugins etc etc.
>> Then the cache is almost useless if you have frequent additions to the
>> board.
>>     
>
> But it would be very usefull for a board with only a few additions a day.
>
>   
But still,
if teh cache is flushed one time a day, and google is going to index 
that page and all
links in that page. The server get's badly hit.

> Probably it would be better to make it possible that an extension can
> change the cache of the page by itself and make additions or replace
> some text by other text, change attributes.
>
> - Franz
>
> _______________________________________________
>   


Since I don't think there is a holy grail for caching.
it might be an idea to have an advanced caching API.
Something a extension can call for itself
flush parts of the cache etc.

That means that a extension will always be user_int,
but can call the cache API first and he can decide if it is time
to refresh the cache or not.

Just some 'thinking out loud'...

Ries