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>
