TYPO3 Core

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.