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