On Mon, 2013-03-25 at 15:26 +0000, Arun Raghavan wrote: > On Mon, 2013-03-25 at 16:35 +0200, Tanu Kaskinen wrote: > [...] > > > > === Improvements Related to Configuration === > > > > > > > > '''Problem statement:''' There are a couple of separate problems: > > > > * If setting some option in a configuration file doesn't seem to have > > > > any effect, chances are that it's being overridden in some other file, > > > > but which file? It's slightly tedious to manually look in several > > > > directories and check the file contents. It's even more cumbersome when > > > > debugging a problem remotely, when it's necessary to explain every step > > > > that needs to be performed. > > I think this would be a _lot_ of complexity for limited gains. Am I missing something? This doesn't seem that complex. You'd have to keep the configuration structure in memory, which you have to do anyway if you want to have a "real configuration system", and after that's there, you just need to annotate each option with the origin information, which is easy to get while parsing the files. Extending the native protocol is tedious, but I wouldn't call it complex. The additional protocol code would be very self-contained. > > > > * Changing a configuration file requires restarting the server before > > > > the change takes effect. > > > > > > > > '''Suggested solution:''' > > > > * When reading configuration files, the daemon should store the origin > > > > file of each option separately. This information should then be made > > > > possible to query by clients. Then, pactl (a command-line utility for > > > > interacting with the server) should be extended to provide a command > > > > that prints the configuration of the running server, and also the origin > > > > file of each option. This functionality would probably apply only to the > > > > "ini-style" configuration files. Those cover most of the !PulseAudio > > > > configuration, with the notable exception of the startup script. It > > > > might be useful to also record the loaded startup script(s) so that the > > > > startup sequence can be queried for debug purposes. > > > > * Sending SIGHUP to the server process should cause it to reload its > > > > configuration. This too would probably apply only to the "ini-style" > > > > configuration files, not to the startup script. It's probably not > > > > possible to make all configuration options changeable at run-time, but > > > > that's OK. > > > > > > Hmm. This sounds like a lot of complexity for little gain. And potential > > > bugs only affecting those who are using this not-so-widely-used feature, > > > I assume. > > > > Are you referring to the second point only, or both points? > > > > I don't think the second point is for little gain. Sure, just reloading > > the configuration on SIGHUP (or whatever mechanism) isn't that > > interesting in itself, but runtime-changeable configuration is required > > anyway in order to support configuration GUIs. I considered adding a > > client API for writing configuration options to the project idea too, > > but there seemed to be enough stuff in the idea already, and having such > > an API has some problems (mentioned in this[1] message) for which we > > would need to agree on a solution first. > > I think this is better solved by using a real configuration system that > can notify you of configuration changes. > > If we can discuss and hammer out details well before the start, this > could make a pretty good project. I did intend this project as the start of a "real configuration system". Apparently what I suggested conflicts with your idea of a real configuration system, so let's find out where our differences are. We discussed this last spring, and I even wrote a proposal document[1]. What I very much don't like about that proposal is that it treats the client-facing configuration API as an inherently separate interface from other APIs. In my view configuration options are just one kind of object properties among other object properties. The only special thing about the "configuration" properties is that those properties are persistent, that is, they are written to disk and restored later when restarting the program. I don't see the point of adding another API for getting and setting configuration options, if the options are anyway already exposed as object properties in the main API. We could avoid the duplication by not adding any "configuration" properties to the main API, but that only results in having two identical object trees, one of which contains persistent properties and one that doesn't. I know that I just proposed a new interface for accessing the configuration, so am I contradicting myself? No. The origin information is something that doesn't fit to the main API, so a separate API could be added just for querying that specific information. [1] http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ConfigurationSystem -- Tanu
