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

[Justin Chudgar]

Some thoughts from a user perspective...

On 01/29/2013 07:27 AM, David Henningsson wrote:
> 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?
Absolutely, one of the more appealing things about pulseaudio is the
very clean, simple and effective command language. The fact that `pacmd`
and the configuration files use the same exact syntax makes the learning
curve exceptionally flat. Using the same or a very similar syntax and
file location(s) for ALL pulseaudio settings would be wonderful. To me,
this is the beauty of Linux/*nix -- most everything is either an
executable file or a text file.
>>>>
>>>> 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.
If `module-rtp-manager` saves its settings in `~/.pulse/rtp.pa`, I would
think that "#include rtp.pa" in `default.pa` would allow both manual and
managed settings to be clearly organized.
>>>>
>>>> I don't think the settings storage format makes a big difference when
>>>> trying to figure out why a specific module is loaded,
I've had problems with modules "appearing" after I had removed them from
`default.pa` because I had forgotten about `paprefs` settings. I would
recommend that everything be stored as text, in reasonable clearly named
files. For example, "~/.pulse/default.pa", "~/.pulse/paprefs.pa",
"~/.pulse/manager.pa", etc. That way, a simple "ls -t" shows what
settings have been changed recently.
>>> 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)
To me, there is a relatively standard way of presenting this
graphically. Rather than torture the english language with a
description, I'll just reference an example that I think fits well:
KDE's System Settings - Autostart page. It quickly and clearly shows
what is enabled and allows one click access to detailed "properties"
editing.
>>>    * Possibly a way to get/set in what order modules are loaded at
>>> startup, but not sure if this is really needed.
Seems like the ordering is could be handled by using something
like`.iffail \n load-module module-silly host=rabbit \n .thenfail
load-module module-boring \n .endiffail`
>>
>> 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.
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: justin.vcf
Type: text/x-vcard
Size: 150 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20130129/b3c36579/attachment.vcf>