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