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

[Bernd Wilke]

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.

> 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.

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)
 
> 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. 
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? 

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

and on the other hand: while you can ignore those version-range nearly
nobody cares about those data.

Bernd

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