[TYPO3-dev] Drop no_cache (was: Re: Announcing TYPO3 4.2 Beta 3)

[Michael Stucki]

Hi Dmitry,

> Ingo Renner wrote:
>> An option was introduced to completely turn off the no_cache parameter,
>> although this option is off by default it is likely that is will get
>> enabled by default with TYPO3 4.4 or 4.5, please make sure you use
>> proper caching in your extensions. A new input field type is available

I repeat: The option is disabled by default. We are talking about future
plans which have nothing to do with TYPO3 4.2...

I think you all agree that the no_cache feature is adding a big factor to
overall performance of TYPO3 websites. If we want to get rid off it, we
need to start somewhere, so this is why this switch was so important to me.

> I think disabling no_cache is a very bad idea. Instead set_no_cache()
> should be disabled from extensions. The  way to do it is simple: save and
> restore value of no_cache var in a local var of tslib_cObj::USER()
> function. That's all. Sometimes no_cache makes real sense and disabling it
> completely is a bad thing.

We had already a little Skype conversation about it, so these are just notes
about my future plans:

- the &no_cache GET parameter is currently used in plugins which could
  simply be USER_INT/COA_INT objects.

=> What we need is a simple way for on-the-fly switching inside of a plugin.
   (Joey described a nice way of doing it, consider having a look at it...)

- sometimes developers use &no_cache when they want to be sure that the
  cache doesn't mix up their output, so this is still a valid requirement

=> A possible solution could be to keep the &no_cache GET parameter but
   allow it only if it matches the devIPmask. (that's just an idea for now)

- the admin panel is also often used to disable caching. This will currently
  not work either. I consider this a bug and will write a fix for it yet
  before 4.2 is final.

- some extensions that call $TSFE->set_no_cache() are in 99% faulty. We
  should make the authors aware of the problem, provide documentation and
  run presentations. In the end, the method should be turned into a private
  one so calls to it will result in a broken extension. (I think it's
  inevitable that extensions will need to be modified to get this fixed.)

(Did I miss one valid reason for using $TSFE->set_no_cache()?)

> I am not sure who had the idea to disable no_cache. I do not remember
> seeing it in core list. But I doubt we can set it by default to "disable".

It was me, see RFC #6547.

> This is bad idea. Machine must not try to be more clever than human.

Nice wording :-)

Imagine a site which was built entirely without no_cache usage. If you are
the admin of this site you want to keep control of this behaviour. So what
you can do now is to enable the flag and get notified by syslog if some
script has tried to trigger it. Instead of checking everything
pro-actively, you can now do it subsequently.

On the other side, extension authors may also want to see how good their
extensions work if no_cache is disabled, so now they have a simple way to
do so.

As I said: It's just a small step on the long road to get rid off no_cache
usage. But we need to start somewhere. At this time we should not worry
about it too much, but I look very much forward to the day it is
removed... :-)

- michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/