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

[R. van Twisk]

Bernd Wilke wrote:
> On Thu, 29 Mar 2007 10:43:25 -0500, R. van Twisk wrote
> with subject "Re: [TYPO3-dev] set_no_cache is bad. What's next?":
>
>   
>> Dmitry Dulepov wrote:
>>     
>>> Hi!
>>>
>>>  From time to time I see that people try to use $TSFE->set_no_cache() in 
>>> extensions. You know what happens next: no caching for pages, 
>>> performance is terrible, web server is not responding, etc. At the same 
>>> time, sometimes, in really rare cases caching must be disabled. But 
>>> definitely not this way from extensions.
>>>
>>> Should we change this function in some way? Should it explain people 
>>> that using it is no-good?
>>>
>>> Personally I would vote for radical methods like (1) keeping it but 
>>> emptying or (2) writing commented phrase inside generated FE page that 
>>> set_no_cache was used, so do not expect good performance.
>>>
>>> Any other ideas/opinions?
>>>
>>>   
>>>       
>> Hey Dmitry,
>>
>> when I started with typo3... I also fell into that function.
>> set_no_cache() for me (back then) did mean no caching for
>> the current extension, instead of no caching for the entire page.
>> The function name wasn't clear enough, and I didn't knew (back then)
>> were to find the correct documentation for it..
>>     
>
> me2
> and I think there are some people more.
>
> we may need two functions:
> 	set_no_plugin_cache()
> 	set_no_page_cache()
>
> and then after a while the original function may become obsolte or just
> call set_no_plugin_cache()
>
> or having a compatibility mode switch on installation deciding where to
> map.
>
>   
I would have expected these two function names... I wouldn't want to 
have more
switches in the install tool. This will only create more confusion.

I also wouldn't want to call set_no_page_cache() from  set_no_cache() 
because that will change
the behavior of set_no_cache() and  people might not expect it.
I think it's still best to shell out set_no_cache() and create the above 
two functions.



 
>> What we can do is slowly depreciate the function creating, however
>> we need to notify the user, and in some way the extension owner.
>>
>> These two options spring into my mind.
>>
>> 1) We setup some rules on TER that can search for these functions.
>> And send the maintainer a mail about that a function is going to get 
>> depreciated.
>>
>> 2) We can setup typo3 in debug mode. And every time a depreciated 
>> function is
>> going to get called we show that on the screen.
>>
>> something like:
>>
>> DEBUG: set_no_cache(); is going to get removed in 4.5
>>     
>
> That might be very anoying for users of extensions they haven't developed
> by themself.
>   
They idea is that it will only be visible when a debug switch is turned 
on. When the debug
switch is turned of the message will not be visible on the FE.
> what about a compatility-log: each function to be removed can write to it
> and may dump the stack or just the paramters to have a posssibility to get
> a hint to those extensions which may not run anymore in future.
> (maximum of ?? KB to avoid spaceexhaustion)
>   
The thing about such a compatibility log is that nobody will take a look 
at it,
or forget to look at it... Unless we show it up somewhere always. People 
(including me)
tend to be lazy.... So we need to make it visible and 'force' the user 
more or less to take
action on it. Of course teh FE experience is not going to be affected...
>  
>   
>> By depreciating functions we can make sure that we keep on growing
>> typo3 and at the same time remove our 'mistakes' from the libraries.
>>     
> +1
>  
>   
>> The bad thing is that it might get more hard to update a typo3 installation
>> because of the use of old extensions with new versions of typo3.
>>
>> However, I do feel that something needs to be done and by notifying people
>> on time (like 6 months or more ahead) we can keep on using the current 
>> codebase
>> effectively.
>>
>> It also makes sure that extensions are going to get depreciated or 
>> getting updated.
>> But not left alone right now.
>>     
>
> I think we/an extension-developer might need a good opportunity to decide
> on which versions an extension can work. There is a possibilty to declare a
> version-range for an extension. but I don't have all versions available to
> test my extensions. 
>   
I am not sure if it will help...
For sure I will not test it to anything then my current development 
installation.

I like the current version compatibility since it just shows 'Develeoped 
on XXX version of typo3'.

> Mostly I will have the newest. At the moment this is 4.1. how can I know
> wether my extension is able to run with 4.0.5, ...4.0.0, 3.8.0/3.8.1 or
> even older installations? 
> And what about newer Versions? 
>   
You don't :) and lickly it will work, just not guaranteed...
> There are extensions to Firefox and every new version disables some of
> these extensions and the developer cannot be reached to test and update the
> version-range of his extension. 
>
> Just imagine, a bigger extension like tt_news has to be completely tested
> with every version: 
> every time there is a new version of TYPO3 (especially a
> bugfix/securityfix) this extension becomes unavailable for 2-3 weeks? =:-O
>   
The problem with a CMS instead of firefox is that we cannot just disable 
a extension because
the system 'thinks' it might not be compatible...
> and on the other hand: while you can ignore those version-range nearly
> nobody cares about those data.
>
> Bernd
>
>