by Howard Tyson
Core isn't really good at either popular type of configuration management. Nothing totally really covers it. I'm in the camp that configuration and content are different but they're connected to each other; exactly where that line is, is not something I'm going to specify.
One problem is that there's no place to store data centrally without loading it on every page load. You have variable_set or hook_schema. No way to tell whether that is content or configuration. Ctools is great, Features implements a lot of that stuff too, if you do the hard work of implementing the Features API. We have no way to connect configuration to configuration, for example whether comments are enabled for a content type. Some of this stuff is continuing to change. We want to store settings and their relationships to each other, and we need unique names everywhere.
Settings can be specified in module code, which can be overridden by the database, which can be overridden by alter hooks, which can be overridden by settings.php.
To be able to deploy content, we have to be able to say that an entry is related to other things in the system. Right now you can implement a hook to specify a new relation, and the API specifies a whole bunch of CRUD stuff for you.
Entity is a bad name because it's not an Entity API entity. But, it identifies a thing with a type and a name. Your 'thing' could also be a node, or a content type. Right now nothing prevents you from doing that.
You can also protect groups, so for example if you did want to do a features export, you could crawl through in a manageable way instead of exporting every freaking variable in your system.
We'll track dependencies, so you can say that a setting is required by another setting. You can also store update callbacks, so every time you rebuild the cache you can call the callback to allow the module to make changes, update the database schema, etc.
Here, we want to keep track of everything that's changed, the old setting and the new setting. If each setting is a self-contained thing, then if we want to roll back, we can just set the old one and swap them. The callback the first time would get old setting and new setting, if we want to roll back we can switch these arguments. The idea is to do a Drupal recovery console. The idea there is that we'd first set the setting, and then figure out the notification system. There's still places that could go wrong.
The log serially increments, but you can use the DB:TNG stuff to use a separate database. The settings could be deployed to another site and just get picked up when you clear the cache.
The Final Frontier
If we had pluggable systems for storing this in different places, you could push a button and get JSON out, instead of in the database. You could do serialized PHP on disk. We could have a Features-like system for exportable settings in core. You could even have a 'locked site' where people can't changed settings that have been 'locked.'