Feature #81436
closed
Story #81432: Replace TYPO3 caching solution with PSR-6 / Doctrine capable alternative
Introduce concept of "Communicators"
0%
Description
As part of replacing the caching framework with a PSR-6 solution, the current consumption of Memcache, Memcached and Redis (and other) APIs should be refactored into a separate concept which allows TYPO3 users to name, configure and consume these "communicators" and through this, be able to configure how a given cache implementation communicates with the service that stores the data. Having a set of configured+named "communicators" is also useful in other contexts, so rather than discarding the method used to configure cache backends that use these APIs, they can be refactored to communicators (which support the same options as the cache backends did).
General for the PSR-6 cache pool implementations is they require an API object (\Memcached for example) as constructor arguments. By defining these "services" as a set of communicators we can refer to a named communicator, or create a communicator from a source array.
The result is that cache configurations can refer to storage services by name and allow users to configure these named services. Or users can declare a completely separate communicator in the configuration for a specific cache.
Resulting communicators:
- ApcCommunicator
- ApcuCommunicator
- FlysystemCommunicator
- MemcacheCommunicator
- MemcachedCommunicator
- PredisCommunicator
- RedisCommunicator
This set of communicators would be delivered by the TYPO3 core but can be extended with as many custom communicators as required.
Updated by
Updated by Christian Kuhn almost 3 years ago
- Status changed from New to Closed
Hey. It seems work in this area is completely stalled since 4 years. A couple of issues have been resolved, the cache API has been streamlined a bit.
I'm about to close the story and related issues for now: They are active action points, but stalled.
I guess if PSR-6 is picked up again, some solution would be different from what has been worked on 4 years ago. If single issues are still appropriate, they could be re-opened and re-attached to a new story again. Other than that, there seems to be little value in still keeping them open at the moment.