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

[Tanu Kaskinen]

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