[TYPO3-50-general] Caching on object or plugin level

[Elmar HInz]

Hello,

I want to open this thread with this mail from the ECT list. We are able
to prepare a MVC library with V5 in mind on top of V4. But we will
probably not be able to implement object caching. So we want to forward
this analyse of the current situation with the questions what is planned
for V5 in point of caching on object or plugin level.

Regards

Elmar


> Hi Steffen,
>
>> I think the confusing comes from deciding: make link with or without 
>> cache
>> (link to an USER object with(ot) cache, link to a USER_INT object 
>> with(out)
>> cache - does the combinations really make sense ?)
>
> The simple rule of thumb: Only USER as target need a cHash in the link
> because only those will be cached in different versions.
>
> For the USER_INT plugin as target the presence of a cHash is of no
> harm itself. *BUT* the problem occures if you send a cHash with it and if
> $GLOBALS['TSFE']->reqCHash(); is set at the same time. The same page
> would be cached many times for the different cHashes. This may blow
> up your database if the source of the parameters has a huge amount of
> possible combinations. That is why we should avoid to send a cHash to
> USER_INT objects in this special cases.

this is a good example where you have to change more than one vars to get 
the right result.
And this logic shouldn't be done by extension (developer). There must be an 
intelligent logic by core for that.

>
> The perfect solution would be an "Intelligent Link" Intellilink (R), that
> discovers itself if the target is a USER or a USER_INT. For different
> reasons that is practically impossible to do. So you need to supply the
> link by hand with this information. If you switch the target from USER to
> USER_INT you maybe like to change all links to it. See the previous
> paragraph.

exactly

>
>> Another point, which makes it difficult for me:
>> A page has several objects. If there is at least one USER-Object, the 
>> Page
>> has to be cached with cHash. But this could not be decision of a single
>> object. And this is the point where all comes really complex. I still 
>> wonder
>> how it works, because it works, but many developers using "dirty tricks" 
>> to
>> prevent the cache like adding a no_cache-param.
>
> Combinations is the most difficult field. There are usecases where
> combinations make sense. But there are also combination that don't give
> sense. I give 3 examples:
>
> 1.) USER_INT without parameters:
>
> Maybe it the USER_INT plugin contain a clock are counter and are not
> controlled by parameters at all.
>
> 2.) Details page:
>
> You need the result set to be a USER to be indexed for search. There can
> by timely changing context lists that are dependent of the ID of the
> the details data set page. They can be USER_INT. They share the designator
> and the one and only parameter.
>
> 3.) Now you have scenario 2 and you want to sort the context lists. Here
> you come to the limits of TYPO3. To sort you have to send different
> combinations of parameters. To cache the details page for the search
> engine you need a cHash. The combination of both would result in a very
> large number of cached pages. Your database would be blown. Here we would
> need caching of plugins instead of whole pages. That would solve all
> headaches at once.
>
> Regards
>
> Elmar
>

that's a very good point. This needs an intelligent cache mechanism, that 
looks for each object for cache version.
I'm not sure if this will blow up the DB too, but for me sounds more 
effective than caching the same page a lot of times with inside some 
recurrent content.

I don't know what the 5.0-Team plans for caching, may be we should ask them.

vg  Steffen