'Twas brillig, and Lennart Poettering at 17/10/11 12:30 did gyre and gimble: > On Mon, 17.10.11 10:33, Colin Guthrie (gmane at colin.guthr.ie) wrote: > >> >> 'Twas brillig, and Lennart Poettering at 17/10/11 02:48 did gyre and gimble: >>>> 3) On Solaris, the PulseAudio GConf module does not compile since the >>>> "module_info" structure defined in the PulseAudio code conflicts >>>> with a structure with the same name in /usr/include/sys/stream.h. >>>> Could the PulseAudio code be updated to use a more unique PulseAudio >>>> specific name as suggested in the patch in this bug: >>>> >>>> https://bugs.freedesktop.org/show_bug.cgi?id=41823 >>>> >>>> Note that sys/stream.h is included by sys/types.h on Solaris, and >>>> sys/types.h is included in the src/modules/gconf/modules-gconf.c >>>> PulseAudio file. >>> >>> The GConf code probably should go away anyway, and be replaced by dconf/gsettings. >> >> While dconf/gsettings is an option, I'd be more in favour personally of >> using whatever pa_database* stuff we use (this was my intension in this >> area with module-loader). > > Well, private database do not have change notificiation, which makes > them a pretty useless replacement. Depends how they are hooked up - see below. >> I'm certainly not against dconf or whatever, but if we do migrate >> module-gocnf to it, then I'd prefer to see dconf as a universal database >> provider in PA like gdb, tdb, plaintext etc. Having two different >> mechanisms of writing data to disk doesn't seem like the wises plan overall. > > Nah, I don't really agree. Configuration is configuration. Remembering > state or learned rules is remembering state or learned rules. The former > is something you might want to share with other apps, the latter > something that is private to you. The former is something you need to > have a clear schema for, so that external code can interfere with it, > but this isn't needed that much for the latter. Well the general plan was to provide a protocol extension to allow for modules to be defined. This would obviously be accessible via the protocol and thus the whole subscription system is available. This provides more than enough structure for "change notification" That said, I'm not specifically against using dconf, but the semantics for module loading will become more complex and thus any client implementing it will have to implement that logic accordingly. Looking at it in as detached a way as I can allow myself, neither argument is particularly strong (i.e. the internal storage using gconf or module info using built in databases). Having a defined schema for the internal data is not necessarily a bad thing and likewise allowing external apps to fiddle with it could be useful. And similarly, providing define ways to configure module loading with certain useful features (like a trigger sink and/or trigger source - e.g. only load module-loopback when both $sink and $source are available) is something can could be pretty easily defined with API extensions like how stream-restore works. The latter has both pros and cons - pro being that it may be useful for setups where dconf might not be available, and cons, it's more API to write, document and keep working into the future. Anyway, we can argue the toss over this next week sometime :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
