[pulseaudio-discuss] RFC: Configuration system

[Peter Meerwald]

Hallo Tanu,


> == 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

I find this explanation quite confusing;

is 'option name' the same as 'option id'?
I suggest to avoid 'option name' so that 'option id' can be understand as 
being part of the (multi-part) identifier; 

maybe 'setting id' would be preferable instead of 'option id'
currently, as I understand, the 'option id' is part of the (multi-part) 
option identifier and hence option identifier and option id means 
different things yet sound similar

> (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

so what is an object type? what are possible types?
what is a 'key', is it the same as the (multi-part) identifier?

> 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

is type and namespace the same thing?

> 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.

> >From the configuration system's point of view, all option values are
> strings. Adding type information would add a lot of complexity and not
> have very big benefits (is it so?). The options will of course have an
> implicit type to be useful. The actual users of the options
> (applications and code in the server) have to validate the values
> themselves. This means that we should provide parsing functions for
> clients, at least for any complex types, but preferably also for simple

for _all_compley types

> stuff like integers. At server side, values are validated when they are
> read from the disk and when they are set by clients or by some other
> code in the server than the "option owner".
> 
> Since validation is done by the option owner code, and since modules can
> implement options, some of the options can be only validated when a
> specific module is loaded. The way to handle the case, where an
> application sets an option for a module that is not loaded, is to refuse
> to set any such options. If the module isn't loaded, from the
> configuration system's point of view the option doesn't exist.

> typedef void (*pa_server_configuration_cb_t)(
>                 pa_context *c,
>                 const char *object_type,
>                 const char *object_id,
>                 const char *option,
>                 const char *value,
>                 int eol,
>                 void *userdata);

so option is indeed option_id? or setting_id as I suggest

> == Open issues ==
> 
> The namespace concept might need some refinement. The idea of splitting
> the storage into one file per module sounds nice, but it might not sense

it might not _make_ sense

> to dedicate each object type to one module. Modules may want add options

want _to_ add

> to their own object types and to core object types, and possibly also to
> other modules' types. Let's say there's an object type "Card" in
> namespace "core", i.e. "core.Card". The alsa modules might want to add
> an option to core.Cards for enabling and disabling timer-based
> scheduling. Maybe the options should have namespacing too, i.e. the new
> option would be "core.Card/foocard/alsa.tsched"? Would every option name
> have a namespace part? That would be very ugly. How would this example
> be handled in storage? Is splitting the storage into many files a bad
> idea anyway?

how does this mix with dbus properties?

> Is there need for adding an API for clients for querying whether a
> specific option is supported? Such API could be added also later, if we
> are not certain yet.

querying a default value or values might be useful as well

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)