Hi, I have written a proposal about a new configuration system to the wiki: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ConfigurationSystem For easier commenting on the mailing list, I'll copy the wiki markup here: = Configuration System = Status: '''draft'''. This is the initial proposal by Tanu, so there may be many opinions that are only held by him. The idea is to keep this page as a reference while discussing the configuration system, and record the results of the discussion here. == Introduction == One of the [[Software/PulseAudio/GSoC2012|Google Summer of Code project ideas for 2012]] was a "configuration system". The configuration system was not among the selected projects, but the system was seen as a priority, so the plan now is to design and implement the important bits (the client API and the server-side infrastructure) ourselves within May 2012 or so (the reason for the tight schedule is that we'd like the GSoC students to benefit from this new system). Porting the existing configuration to the new system is not a matter of urgency. All the existing stuff has to be kept in mind while doing the design, though, so that the porting work is possible to do when that time comes. The configuration system should make it easy to implement runtime-modifiable persistent configuration options in the core and modules. Currently that involves writing protocol extensions (for multiple protocols, if you aim for completeness) and managing the data storage yourself. The goal is to reduce that work, and also to make life easier for applications. There are some notes from previous discussion at [[http://piratepad.net/BLGxYG2lf3]]. == Goals == * The client API should be easy to use. * The set of supported configuration options should be easy to extend. * No protocol extensions. * Make it as easy as possible to add a new option. * Support also other things than statically named global options. * For example, options for ports requires dynamic keys to identify the port. * We want (or do we?) to support also persistent data that is less configuration-like, like the stream-restore database or the equalizer data. * Support change notifications both at client side and at server side. * Support reading and modifying client.conf. (?) == Design == The configuration system stores "options". Options have a value and a (multi-part) identifier. The options need at least two pieces of identification information: the object id and the option name. For example, the maximum volume of a port could have object id "foocard:barport" and option id "max-volume". Objects have also a type (e.g. card, port, stream-restore entry). The object ids could have the type information encoded into them, or the type could be a separate identifier. A separate identifier is better, because otherwise you need to store the known options for each object, while it would be easier and more efficient to store the known options for the type of the objects. So, option values can be referenced by giving three identifiers: object type, object id and option name. These can be encoded in a single key string (e.g. "core.Port/cardname:portname/max-volume") if so desired, but the configuration system has to have concepts for these three things. We might want to also have a type namespace concept, for example to split the configuration into one file per namespace (core could have its own namespace and each module could have theirs). In the client API it's probably best to encode the namespace into the object type.
