[pulseaudio-discuss] RFC: Getting rid of the GConf dependency

[Tanu Kaskinen]

On Tue, 2013-01-29 at 09:02 +0100, David Henningsson wrote:
> On 01/22/2013 10:43 PM, Tanu Kaskinen wrote:
> > Hi all,
> >
> > GConf is deprecated. We have a bug that asks us to convert to GSettings:
> > https://bugs.freedesktop.org/show_bug.cgi?id=57743
> >
> > As I have written in the bug, I don't really want to move to GSettings.
> 
> So far, I'm agreeing with you.
> 
> But can we take a step back? I want it to be easy to debug the 
> configuration and why a specific module is loaded.
> 
> And you proposed to split the configuration into several .pa files at 
> PulseConf, even if the exact directory structure wasn't really worked 
> out. That seems largely related to this issue.
> 
> I'm just thinking - if we're replacing gconf anyway, can we come up with 
> something more unified/generic that would fit in the new directory/file 
> structure, instead of inventing a new type of configuration storage for 
> this particular problem?

The new "manager modules" that I suggested could store their settings
as .pa scripts. Would that be enough to make you happy?

The scripts could be stored in a location from which they would get
picked up automatically by the main configuration script, or the scripts
could be stored in a location from which they would only get picked up
by the manager modules.

If the scripts were included automatically by the main configuration
script (default.pa), that would have the problem that when a manager
module is removed from the configuration, its settings are not cleared
automatically. So if the user removes module-rtp from the configuration,
unwanted rtp modules may still get loaded. Therefore, I'd prefer the
manager modules to control the module loading instead of including the
scripts from the main configuration script.

I don't think the settings storage format makes a big difference when
trying to figure out why a specific module is loaded, so maybe you're
having problem with the whole "manager module" concept?

-- 
Tanu