On 03/22/2013 06:01 PM, Tanu Kaskinen wrote: > Hello, > > I added another GSoC idea to the wiki[1], and it's also copied below. > Does the idea make sense? Is there anything in it that should be > changed? Not sure about if I would recommend this one to a GSoC student. It feels like we have quite some stuff to figure out w r t to directory moving, conf splitting etc, that aren't straight laid out yet. If we get all that work thought out, then okay, but if we're unsure of what to do, the GSoC student will be even more confused. > === 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. > * 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. If we go with this, I think we should make it a whitelist rather than a blacklist; i e, figure out a few parameters which are both useful to change at runtime and don't have implications all over the system. Also, why SIGHUP? A native protocol extension seems more intuitive to me. > > '''Contacts:''' Tanu > > '''Necessary background:''' C > > '''Potential mentors:''' Tanu > > [1] http://www.freedesktop.org/wiki/Software/PulseAudio/GSoC2013 > -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
