Hi all, GConf is deprecated. We have a bug that asks us to convert to GSettings: https://bugs.freedesktop.org/show_bug.cgi?id=57743 As I have written in the bug, I don't really want to move to GSettings. I'm starting this thread to ensure that we have a consensus about this, as work on this may start soon by Abhinav Misra, a potential GSoC candidate (if I understood correctly, he'd like to start contributing ASAP). I'd like paprefs to do its thing via the normal client protocol. The reasons are the following: * client.conf doesn't affect how the connection to the GSettings backend is made, so paprefs doesn't follow the same rules for choosing the server to interact with as all other clients (and no network transparency at all). * Redundant communication channels are redundant. In the bug I said that I think that GSettings isn't cross-platform, but I mixed GSettings with dconf. I believe dconf isn't cross-platform, but I'd expect GSettings to be, so that's not an argument against GSettings. Here's a list of paprefs functionality: Network Access: 1. Make discoverable PulseAudio network sound devices available locally 2. Make discoverable Apple AirTunes sound devices available locally Network Server: 3. Enable network access to local sound devices 4. Allow other machines on the LAN to discover local sound devices 5. Don't require authentication 6. Make local sound devices available as DLNA/UPnP Media Server 7. Create separate audio device for DLNA/UPnP media streaming Multicast/RTP: 8. Enable Multicast/RTP receiver 9. Enable Multicast/RTP sender 10. Send audio from local microphone 11. Send audio from local speakers 12. Create separate audio device for Multicast/RTP 13. Loop back audio to local speakers The functionality requires a way to modify the module configuration in a persistent way. The native protocol doesn't currently provide that functionality. I suggest that this is solved by writing a few new modules: module-zeroconf, module-raop, module-client-connectivity, module-dlna and module-rtp. These modules would be loaded by default (if they are available), and they would maintain the configuration. Loading module-zeroconf, for example, wouldn't mean that module-zeroconf-discover or module-zeroconf-publish would necessarily be loaded; by default they wouldn't be. The point of module-zeroconf would be to provide a way to enable those modules persistently via the native protocol. Regarding the vaguely named module-client-connectivity, that module would manage both the native and the D-Bus protocol modules. The reason is that once the D-Bus protocol is actually production ready, in the vast majority of cases it makes sense to configure the native and the D-Bus protocols with the same settings so that clients behave consistently regardless of which protocol they use. Also, paprefs shouldn't need to care about the different protocols when the "Enable network access to local sound devices" option is enabled - it's up to the server to decide which protocols that option enables. -- Tanu
