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

[Tanu Kaskinen]

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.

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. 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.

> 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).

>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.

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. 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.

-- 
Tanu