[pulseaudio-discuss] RFC: Configuration system

[Tanu Kaskinen]

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.