[TYPO3-v4] Goal of caching framework things

[Christian Kuhn]

Folks.


The current caching framework patches are not a 'just because we can' 
thing, but are part of a bigger refactoring, it is just one step into 
the right direction (as we think).

We recently enabled the caching framework (cf) by default for TYPO3 4.6 
and removed the 'old' caching. This is imho a leap forward to a cleaner 
core, but we still have some open issues that must be tackled.

Since I am one of the main drivers in this project here are the most 
pressing points from my side I'd like to spend my energy on:
- Finally consolidate the upgrade path raised by discussion 'Current 
master branch is broken?' in this list. I hope my latest outlined 
solution is solid enough to tackle all concerns.
- Analyze the sysext/lang scenario from 
https://review.typo3.org/#change,2930 , maybe raise a discussion about 
this, find a solution and get it done.

There are some further things that would be great before 4.6 feature 
freeze. I'm unsure what can be done within given time, but these are the 
main points:
- Create a solution for a 'hybrid backend'. This backend should share 
data and tags in two different backends. This could solve the file 
backend performance and the memcache corruption issue and has further 
benefits. I have a draft for this at hand, but any solution must be 
pushed to FLOW3 first and ported back again (I did not yet get an answer 
by Robert for my request of the draft).
- *Maybe* hack up an additional "pass through" frontend that does no 
serialize at all for backends but accepts strings, arrays and objects 
directly. This would be useful for transient memory backend, but must be 
profiled before and must be pushed to FLOW3 to back ported afterwards.
- Review *all* current core cache usages and do more abstraction. For 
example I see no reason to separate cache_hash and cache_pagecontent and 
things like that anymore. Caches should only get an own namespace if 
they could potentially grow very big, are different things or can not 
share same cache name space for reasons.
- Add a standard 'php cache'.
- Initialize cf more early in bootstrap and use it in the autoloader 
using a new php frontend cache. I have a patch for this that just needs 
some adaption. There is already a bigger plan for a bootstrap 
refactoring and we will likely raise this topic during DevDays.
- There are many more ideas on what can be done if we have a working cf 
during bootstrap (for example a concatenated file of all important 
global arrays that can be loaded with one require_once). but these 
things are pretty far away currently. We have to set up a foundation for 
this first.

This whole thing aims to create a solid base for a better, quicker and 
more transparent TYPO3 bootstrap, extension registration and handling of 
core dependencies. We've got feedback from different developers that 
this is the right way to go, but we have to take one step after another.

It would be great if people step in at specific tasks, I'm sure the 
DevDays has some opportunities to talk to each other in this regard.


Regards
Christian