On Thu, 2012-04-26 at 19:28 +0300, Tanu Kaskinen wrote: > On Thu, 2012-04-26 at 14:19 +0200, Peter Meerwald wrote: > > 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 > > Good points, I'll make the terminology more consistent. I would prefer > "option id" to refer to the whole three-part identifier and "option > name" to the last part of it. I'm not very keen on switching one or the > other to "setting" - to me that would seem inconsistent. I wonder, > though, if there would be any reason to completely switch the word > "option" to "setting" everywhere? To me (a non-native English speaker) > "option" and "setting" mean the exactly same thing in software context, > but is there some distinction that would make one or the other a better > choice? I have now rewritten much of the "Design" section. Hopefully it's clearer now. > > > 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? > > Interesting question. With the currently planned feature set, I would > just add a similar get/set interface to the D-Bus API like the C api is. > If you meant how the namespacing choices affect Pulseaudio's D-Bus API > (I assume you meant that), the answer is that the choices don't affect > the API at all. That's because the API doesn't have any concept of > namespaces anyway. > > With a slightly larger set of features (like proper types associated > with the option values instead of just strings) the options probably > could be automatically mapped to properties in the D-Bus API. And with > some more features, the D-Bus, native and HTTP interfaces could just > talk to the "configuration system" (or "object introspection system" at > that point), and new features would automatically get support in all > those interfaces... That would be nice, but not what I want to start > working on now. > > Anyway, thinking about how D-Bus would do this might prove fruitful. If > the options were modeled as properties in D-Bus, then the object type > would be the D-Bus interface and the object id would be the D-Bus object > path. Trying to add new properties to an interface at run-time (like > adding the alsa.tsched option to core.Card) is not supported in D-Bus. > The solution would be to make new interface, let's call it > "org.pulseaudio.alsa.Card". The documentation would state that the > "org.pulseaudio.alsa.Card" interface implies that the object implements > also "org.pulseaudio.core.Card". That would imitate a concept of > subinterfaces. I actually like this solution. The only problem is that > you can't enumerate all options of the card with a single query, so you > have to ask for the "core.Card" and "alsa.Card" options separately. This > shouldn't be a significant problem in practice. > > So, you can document some object types to be subtypes of other types. > There won't be explicit support for extending the option set of an > object (or object type). There's no need to add namespacing to option > names. This has been now added to the "Design" section. > > > 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 > > Yes, sounds like a possible addition. I didn't add this yet. The system certainly needs to know when an option value is set to be "the default". When a new version of Pulseaudio with changed defaults is installed, the new default should be used if the option is set to "the default". But if an option is set to a specific value that happens to be also the default value in the old version, the value shouldn't be changed to the new default. I think "reset to default" functionality would be useful, but I'm not so sure about querying what the default value is. What would be the use case? There's some possible complexity arising from having the "ask what the default is" functionality. Some defaults are such that they depend on stuff like compilation options. I would be surprised if there weren't any options whose default value depended on some thing that can change at runtime. If such options are possible, should we also add an API for getting notifications about default value changes? On a different topic, I have added an API for getting notifications about added and removed object types. Hmm... now that I think of it, if we have the notification API, should we also have a query API for getting the currently available object types? I think we should, for completeness. The same information could also be acquired with pa_configuration_system_get() using some wildcards, but I think that would be a bit clumsy. -- Tanu
