- Introducing KeyValue/FileStorage.
- Demonstration: Replacing State with FileStorage.
- The entire point of rewriting CMI 2-3 times was to decouple the storage from the application-level configuration concept.
- The underlying storage is nothing else than a key/value store.
- The custom concept of a "ConfigStorageInterface" should not exist to begin with.
- The current FileStorage is a key/value store, because key=filename, value=string, collection=subpath.
- There should only be one concept of a key/value store in Drupal and it should be used wherever applicable. Let's ensure that the configuration system does not re-invent that wheel.
The encoder/decoder for the serialization format should simply be injected, the storage doesn't care.
I wanted to suggest Drupal\Core\Serialization first, but then I wondered how the REST/Serialization module is handling serialization formats. I learned that we apparently have the Symfony Serializer component in core and REST/Serialization is a simple wrapper around that (for REST-specific purposes, not sure I get why those are separate modules...)
→ Use whichever serialization encoder you want to use. The key/value store does not and should not care.
In case Serializer is too slow/big/complex of a dependency, then let's simply do Drupal\Core\Serialization and provide standard implementations for serialize/YAML/JSON/YML that can be injected.