[TYPO3-v4] Goal of caching framework things

[Xavier Perseguers]

Hi Christian, Hi all,

> 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.

It is a good explanation of why it crashed for a few people and how it 
works. Thanks for that. I'm convinced we'll find a viable solution based 
on the ideas found in that thread.

> - 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.

Part of the XLIFF refactoring.

> 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:

XLIFF is one of those major changes for 4.6 we want to be bullet-proof 
in order to hopefully being confident backporting it to LTS. The second 
is this caching framework refactoring. I like the way it heads to very 
much but to be honest I did not yet test it "again" with either a 
upgraded or a vanilla DBAL-aware install. I plan to do so next week, 
during T3DD11.

> - 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.

Feature freeze is coming really soon. I'd like to coordinate very well 
with v5 with this "commit-here-backport-there" workflow to be sure we 
keep our momentum and do not loose time. It would be a pity to not being 
able to get some well-thought and proven idea because of a lack of 
review somewhere. In short we should target those discussions/reviews 
during T3DD11 I'd say.

> - 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.
> [...]
>
> 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.

Sure. I suggest to discuss the concept of such possible near-track 
workshops during the Core team meeting.

Regards

-- 
Xavier Perseguers
Release Manager TYPO3 4.6

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org