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

[David Henningsson]

On 01/29/2013 02:47 PM, Tanu Kaskinen wrote:
> On Tue, 2013-01-29 at 12:03 +0100, David Henningsson wrote:
>> On 01/29/2013 11:01 AM, Tanu Kaskinen wrote:
>>> 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.
>
> I'm not sure if I expressed this clearly: in my proposal clients won't
> manage modules directly. For example, paprefs wants to enable network
> access, and pulseaudio provides an interface for that exact operation.
> paprefs doesn't tell pulseaudio to load module-native-protocol-tcp and
> module-dbus-protocol with argument "access=remote". Instead, whatever
> code implements the "enable network access" operation will control what
> modules will need to be loaded with what parameters.

This sounds like an abstraction layer. I doubt the abstraction layer is 
worth the added complexity here - paprefs is a very PA specific utility 
anyway, so referencing module names directly would be okay.

> One reason why I want to avoid requiring clients to manage the modules
> directly is that clients would need to understand what the set of
> currently loaded modules means. If there are two
> module-native-protocol-tcp instances (with different parameters), one of
> which is the result of the user checking the "enable network access"
> checkbox and one is a manually loaded instance, how is paprefs going to
> tell them apart? Unchecking the "enable network access" checkbox
> shouldn't unload the manually loaded module.

I'm not so sure about this either. If a module-native-protocol-tcp is 
loaded - no matter what parameters - there is some network access 
enabled, and thus it would make sense to check the box in paprefs.

I would also guess people use paprefs for simplicity (if they use it at 
all?), and if they set up module-native-protocol-tcp connections 
manually, they are unlikely to use paprefs too (at least for that thing).

> paprefs could set some
> magic property on the modules that it manages, but what if there's
> another application that also wants to control the same "enable network
> access"? The magic property would need to be standardized. Not
> impossible, but managing the modules at server side would be less hairy.
>
> Having an abstract API instead of direct module management is desirable
> also from security point of view: we might want to allow clients
> operations that result in modules being loaded or unloaded without
> allowing direct module loading and unloading.

Hmm, I thought module (un)loading was possible through the client API, 
but maybe it isn't.
But if we're worried about security - isn't the stuff that paprefs can 
do today just as harmful as module (un)loading anyway? If so, maybe 
paprefs should use a pacmd type approach rather than extending the 
client API?

OTOH, having a more open approach enables people to write their own PA 
configurators without having explicit support for that in PA.

>> 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.
>
> Thoughts about one vs. multiple manager modules: The reason why I
> suggested separate manager modules such as module-zeroconf and
> module-raop was just to keep e.g. knowledge of raop strictly separated
> to the raop modules. Having thought about this a bit, I think a single
> module would be actually nicer. With separate manager modules
> module-raop would be loaded by default, which would probably cause users
> to wonder "I have module-raop loaded, why don't I have any raop
> sinks?" (answer: the "discover raop devices" option isn't enabled) and
> "I don't own any raop devices, why is pulseaudio having module-raop
> loaded?" (answer: so that paprefs can interact with it).

...and less copy-paste between module loading modules.

>  From client point of view it shouldn't make any difference whether the
> "discover raop devices" option is implemented by module-raop or by
> module-preference-manager.
>
>> 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.
>
> As long as there are modules that load other modules, you can't answer
> the question reliably. Whether module-alsa-card gets loaded depends on
> whether there are any sound cards.

Right; it would only be able to answer that for the "root" modules.

> I wouldn't be against making it a convention to not load any modules
> from other modules, though. There's no reason module-udev-detect must
> create the alsa card object by loading module-alsa-card. There could be
> an API for loading alsa cards, like there is for loading alsa sinks and
> sources. Similarly, there could be an API for controlling raop
> functionality without loading any modules.
>
>> 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.
>
> I don't see how you could achieve module blacklisting with some clever
> directory layout.

If we have a file

/etc/pulse/default.pa.d/90-load-very-evil-module.pa

that loads an evil module, and then a

~/.config/pulse/default.pa.d/90-load-very-evil-module.pa

...which is empty, the latter could override the former. I'm not saying 
this is the best idea, just that it is possible.

> I think you need to have a way to set some variable
> prior to processing the system-wide configuration, and if you have that,
> then there's no need to care about the directory layout: to prevent
> module-udev-detect from loading, just put "allow-module-udev-detect=no"
> in the beginning of the user's default.pa and then include the
> system-wide default.pa.

Sure, this would work too.


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