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)
