[pulseaudio-discuss] RFC: PulseAudio's D-Bus interface

[Tanu Kaskinen]

ke, 2009-07-01 kello 01:30 +0300, Tanu Kaskinen kirjoitti:
> ti, 2009-06-30 kello 22:23 +0200, Lennart Poettering kirjoitti:

<snip>

> > Also, we have X11 root window properties for finding the server, we
> > should have that for the D-Bus server too, probably.
> > 
> > Hmm, I am not really convinced that we need to split up the pa starter
> > stuff from normal daemon. I'd rather see a logic like this:
> > 
> > 1) If $PULSE_DBUS_SERVER is set, connect to it, end of story
> > 
> > 2) If X11 root window property PULSE_DBUS_SERVER is set, connect to it, end of story 
> > 
> > 3) If we can connect to /var/lib/pulse/dbus-socket with uuid
> >    /var/lib/pulse/dbus-uuid, use that, end of story
> > 
> > 4) If autospawning is enabled run org.PulseAudio.Server.Activate() or
> >    so on the user/session bus, which might cause PA to started up via
> >    bus activation and returns the bus adddress, connect
> >    to it, end of story
> > 
> > 5) Similar as #4, but on the system bus.
> > 
> > A running PA instance would always take up org.PulseAudio.Server on
> > the user/session bus when run without --system and on the system bus
> > otherwise. It would always return its own address on Activate.
> > 
> > I don't think we should start "half a daemon" as you seem to suggest,
> > i.e. something that would just process the GetAddress request but
> > otherwise do nothing. I think X11 properties are a much more suitable
> > way to discover remote PA servers.
> 
> I'm not convinced yet regarding remote server discovery. "Half a daemon"
> reads the configuration from client.conf, so we can instruct users to
> just edit one variable in that file and disable the local daemon in
> daemon.conf. Now, compare that with X11 properties. I don't know how to
> set an X11 property. I'm sure it's just one simple command, so user
> instructions wouldn't be any more complex... unless the property isn't
> persistent. I would guess X11 properties aren't persistent.
> 
> What if the user doesn't have X? Surely X11 properties won't work in
> such situation?

I realized that the "half a daemon" solution is not good, because if
only a remote server is used, then installing the pulseaudio executable
shouldn't be required. To keep the client logic as simple as possible, I
think some kind of a simple executable is still needed that reads the
configuration. Let's call the configuration reading executable "the
helper" for now.

Either the client calls the helper directly, or the helper provides a
D-Bus service similar to the lookup service in my previous proposal. I'm
not sure which one is better.

In case a local server is configured, I think the helper could take care
of calling org.PulseAudio.Server.Activate() on behalf of the client
(this would also ease the transition to the user bus, btw). This way the
helper can return the server address unconditionally (ignoring any error
cases). Otherwise it would need to indicate in the response whether the
server's type is is user, system or remote, and in case of remote also
provide the address.

-- 
Tanu Kaskinen