[TYPO3-dev] Caching Framework

[Bernhard Kraft]

Jigal van Hemert wrote:

> The whole new caching framework seems a bit overweight for something 
> that should be as fast as possible, such as a caching mechanism. But 
> that has been discussed earlier.

If you dig into the new caching framework, you'll soon notice it is not 
very bloated but rather just "deep" instead of "long" ... So its some 
kind of other dimension ;)

No. Just joking. As far as I noticed the new FLOW3 stuff altogether 
rather tends to put everything into small methdos, which leads to a 
deeper function call stack, instead of implementing functional methods 
each one doing its specialized task.

I guess both kinds of programming are "fine" if you just know what you 
do and where and what piece of code does what.

In the case of the FLOW3 programming style, you'll probably soon loose 
overview over each method which exists and what it does - in the TYPO3 
programming style similar patterns of code repeat in every place of the 
core. So each variant has its advantages and drawbacks ...


> As automaketemplate must always be compatible with all supported 
> versions of TYPO3 there must (in the end) be a way to detect if the data 
> should be (un)serialized or not. If there is such a mechanism I'm more 
> than happy to incorporate that in automaketemplate.

The problem is that the serialize/unserialize is hardcoded into the 
automaketemplate, the same way as it is into the core.

In my opinion, the core or automaketemplate code should never do any 
serialize/unserialize for calling t3lib_BEfunc::storeHash or ::getHash 
but instead let those methods take care if the data should get 
serialized or not.

This would allow storage backends which do not need serialization (like 
memchached, xcache and other shm PHP extensions) to avoid the 
serialization stuff and thus safe precious CPU time.


greets,
Bernhard