[pulseaudio-discuss] RFC: Configuration system
pmeerw at pmeerw.net
Thu Apr 26 05:19:16 PDT 2012
> == 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
More information about the pulseaudio-discuss