[TYPO3-ect] RFC: Caching, USER/USER_INT switching

[Elmar Hinz]

http://t3flyers.wordpress.com/2007/04/04/rfc-caching-useruser_int-switching/

The thread "tx_base - tslib_pibase modernized" in
typo3.teams.extension-coordination shows, that the current system of
caching is to complicated and that the conception is not really clean.

The questions are:

1.) How would a modernized system look like?
2.) How can it be implemented into TYPO3 4.x without breaking existing
installations and extensions?

I summerize my current thesis about this and ask for your comments:

A) Disabling set_no_cache() function AND no_cache parameter

As Dmitri pointed out in t.dev the set_no_cache() function is one of the
most abused ones. It's the same with the no_cache parameter.

A.1) How a modernized system would look like?

I suggest to disable the function of the set_no_cache() function AND the
no_cache parameter in the core, to force extension developers to work
without it.

A.2) How it can be done without breaking existing installations and
extensions?

a) To keep plugins working that make use of the no cache parameter, the
"no cache" checkbox in the BE page form can be used. This BE
functionality should be preserved for this purpose.

b) The same checkbox can be used during development where developers else
would make use the no_cache parameter.


B) If there is a cHash always check & cache

Currently the prerequest is to cache a page is that the URL is signed with
a valid cHash and the the checkCHash parameter has been set from at least
one extension in the page. Because it can be triggert by different plugins
in the this setting is not reliable to controll the caching of a plugin.
This flag is a misconception.

B.1) How a modernized system would look like?

In a modernized version a page would always be cached if a valid cHash
has been send. The triggering with checkCHash is not necassary any more.
The caching can only be controlled by signing a link with a valid cHash or
not doing it.

This system is easy to understand and less error-prone, but it forces the
programmer to cleanly think about each link he generates.

B.2) How it can be done without breaking existing installations and
extensions?

In fact there shouldn't be many extensions that create cHashed links
without wanting the target page to be cached. So this is a very limited
problem.

This extensions are already dangerous today. They result in flodding the
cache tables as soon as they are installed into a page where another
plugin sets checkCHash. This insane extensions will break if cHashed pages
are always cached. They need to be fixed immidately. And that is good.


Some remarks on details

pageNotFoundOnCHashError

Currently we get an error for the configuration pageNotFoundOnCHashError =
1  if we send a non cHashed URL to a page where checkCHash has been
triggert. Here the problem is that the cHash is checked although no cHash
has been send at all. So this is a special case of B). A cHash should only
be checked if a cHash has been send.

How to switch a plugin between USER and USER_INT

One idea of the checkCHash flag has been to enable a simple possiblity to
switch a plugin quickly between USER and USER_INT. Now we need to give a
different answer to this task.

a) Typically we need this kind of switch during development. Now we need
also to keep gard of the links inside and to the plugin. During
development we would set the cHash to false for this links. On deploying
we set them to true. Typically there are only a few links inside an
extension that need a cHash (that to detail views). In case we have many
links we can automate the switching by defining a class variable and
feeding them as $cache parameter to the link functions.

b) In some cases we really want a switch between USER and USER_INT for a
deployed extension. In this case the solution would be similar to a).