So... I quickly discussed the possibility of re-rolling the Cache API on top the k/v interface with @pounard on IRC. @catch You also mentioned that idea briefly over at #1175054: Add a storage (API) for persistent non-configuration state → . What's your opinion now? Currently, the only incompatibility is ->getAll() which might be troublesome for some backends?! We wouldn't really gain much from this other than consistent APIs. And I think the foundation for both APIs actually IS identical.
Also, the KeyValueStore has an $options argument in the constructor. We currently don't have that in the CacheBackenInterface. However, I think that could actually make sense.
Postponed: needs info
9.5
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
With the current state of the cache system on D10 is this still a valid task?
The lack of response to the last comment indicates there is no need for this.
If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.