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

[David Henningsson]

On 01/29/2013 11:01 AM, Tanu Kaskinen wrote:
> 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,

What makes it easier to figure out, would be
1) less files/directories to look in
2) less number of ways to load a module

GConf fails in both of the above. I was hoping we could do better.

 > so maybe you're
 > having problem with the whole "manager module" concept?

Maybe so.

If we try to design this from the client's perspective, i e paprefs or 
possibly other apps in the future, we would essentially need these 
function additions to the client API:

  * Is a module loaded by default on startup (set/get)
  * Module parameters (set/get)
  * Possibly a way to get/set in what order modules are loaded at 
startup, but not sure if this is really needed.

Now whether this is all handled by a "manager module" or by the core is 
an implementation detail, but it seems weird if a manager module could 
remove itself (and I fail to see any point in having several manager 
modules?), so probably it makes more sense to have it in the core.

Second, to be able to accurately answer "is a module loaded by default 
on startup", I assume such code would have to go through all the .pa 
scripts in all directories.

Exactly how to do a user level override, that e g disables a module 
loading of a module that is loaded by default for all users, I think we 
don't have the directory structure to permit that yet, which is why I 
brought the directory structure thing up.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic