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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
