A base StorageInterface needs to be created, with different storage mechanisms that implement it (currently the file storage and database storage are completely separate classes.)
The configuration system was designed to have two storage systems - files and active store. However, it turns out that there are actually more storage systems than that. For instance, there is the default configuration that ships with modules, which is read-only storage. This potentially needs to be referred to at install time, to check if config have changed from defaults, and to reset config to default values. There may be other storages which come down the line. In order to manage this, we should adjust the config system to work with 1:N pluggable storage engines. There are several adjustments that should happen for this to work.
- Currently the config class manages the interaction between the file storage mechanisms. A potentially better solution would be to create a StorageManager class which manages the interaction between the storage engines.
- Define what all of our read/write situations are so that we can architect this properly.
- Manager contains instances of all storage objects and attemps to read or write from or to them as appropriate.
When these two are done the architecture of the config system will look more like this:
It would be useful to provide an interface and base class that implements functionality common to configuration more complex than a collection of settings (image styles, content types, views, etc.) There has been a lot of discussion about what these should be named but the only agreement is they should NOT have the words ‘entity’ or probably ‘config’. For the sake of this discussion we will call them ‘thingy’. Thingy is not really a part of the configuration system, it is just a useful base class for people to extend for more complex use cases.
- Unblocks YAML FileStorage format change.
- Fixes the upgrade path helper function that converts variables into configuration.
- Introduces formal namespaces in configuration object names: the part before the first dot/period.
- Fixes architectural OO design and also slightly performance.
- Separates DrupalConfig, the "storage arbitrator/manager", from actual storage controllers.
- Unblocks Configuration UI work and starts to untangle storage controllers.
- Introduces basic import/synchronization support.
- Required to properly convert variables into configuration.
- Required to fully convert settings forms into configuration forms.
- Required to not have to repeat every variable to config conversion once more for D8.
- Unblocks various Novice conversion issues.
- Re-opens these issues:
- Separates the actual configuration object from the storage controllers.
- Introduces "typed" configuration objects; e.g., Vocabulary + ImageStyle configuration objects (mimicking Entity objects to some extent).
- Introduces high-level Configuration API CRUD functions for module configuration.
- Unblocks all conversions for typed configuration; e.g., entity types, entity bundles (node types, etc), fields, field instances, text formats, etc.
- Enhances import/sync mechanism for complex configuration having (inter-)dependencies (mostly typed config, such as entity types, entity bundles, fields, field instances).
- we need pluggable back ends for config storage so that sites can use something other than the db
- Fixes the performance of retrieving configuration and repetitive calls to config().
- @todo Generic Property API.
- Advances on and to detach the Property API from entities (after detaching the API from fields).
- Unblocks multilingual configuration.
- Leverages Property API to introduce meta data for config object keys; e.g., required, validation, multiple/cardinality, translatable, etc.
- Unblocks translation UI for configuration.
- @todo Configuration UI
Parallel / Anytime
- Depends on formal namespace/owner standard in configuration object names.
Original report by @heyrocker:
The config system was designed before any implementations were done, and several threads have discussed potential cleanups. I'd like to bring all those threads together here and move forward on options. Ideally, these changes would not affect the public API.
One of the most glaring issues is that there is no commonality between the file storage class and the sql storage class. I would like to see this rearchitected so that we have a ConfigStorage interface, and there are ConfigFileStorage and ConfigSQLStorage implementations of it. This will also make a lot of issues likea lot easier to implement. There has been discussion that this new interface should be a generic key/value store (this was discussed somewhat in ) however I'm not sure this will work out. msonnabaum, beejeebus and I tried building this and it had some complications, like that the config system isn't really a key/value store, its a key/key/value store if you will.
While this is happening, much of the functionality that currently lives in DrupalConfigStorageInterface would move up to the DrupalConfig class (for instance synching between files and the active store in the situations where that happens.) DrupalConfig would now hold references to two storage objects - files and active store. Then it can manage the interactions between them within its existing public API functions.
Another thing that needs to happen is we need to figure out how/where to statically cache config data. Incatch suggested we statically cache the config objects in config(), but we could also just statically cache the data within each class. Regardless, a more sane architecture would make this easier at whatever level we decide to implement it.
I know someone is going to bring up whether or not we should do automatic writethrough of to files on save, but I think that is irrelevant to this issue and needs its own discussion where we decide to add a flag to control it that is on by default. (see what I did there?)
I can start mocking this up into a real patch in the next day or two if nobody beats me to it.