pe, 2010-02-05 kello 17:18 -0800, Conor Curran kirjoitti: > I was looking over the DBus notes on the wiki. It seems like there is a > pretty comprehensive DBUS API planned. I only took a quick glance over > the source and could only see outbound connections to HAL etc. The notes > on the wiki from here http://pulseaudio.org/wiki/DBusInterface were last > updated at the end of August. I was wondering what the plans are for this ? If you didn't find the inbound D-Bus code, you didn't look hard enough, or had some other version than git master. The D-Bus stuff hasn't been included so far in any released PulseAudio version. I think it probably will be in the next feature release (as opposed to bug-fix releases, which the two last releases have been). I believe that it will still be declared an experimental feature, and the interface will be subject to change without notice. So if you want to use it, be prepared to face breakages as new PulseAudio versions are released. The "Recent Changes" list on the page you linked is the place to find out about interface changes. The D-Bus interface has been pretty much "my" project. Funding for it stopped last August, and unfortunately I don't "have time" for coding a lot on my free time. Currently I have a sizable backlog of school assignments to do, which I prioritize above coding. It's not really that I'm terribly busy, I just tend to procrastinate... For these reasons, it's possible that the D-Bus code won't progress before May when all the deadlines have passed... Here's a list of the most important things to do before the D-Bus module can be called "ready": * The server discovery needs to be reworked. The current "half a daemon" solution needs to be replaced with a helper service that finds the server address: <https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004437.html> * Related to the previous item, the "server string" system needs to be extended with the dbus protocol: <https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-January/006355.html> * module-dbus-protocol needs to provide the server strings and module-x11-publish needs to use those server strings. This will make module-dbus-protocol seem even more like duplicated effort - it might be sensible to merge module-dbus-protocol.c into module-protocol-stub.c. * Introspection needs to be fixed so that all XML documents contain information also for child nodes. I originally thought that this was optional, so I didn't implement it. * Signal sending code has a bug somewhere that causes signals not to be sent unless the client has requested that absolutely all signals should be sent. This needs to be fixed. * D-Bus itself has to begin supporting "user buses": <http://lists.freedesktop.org/archives/dbus/2009-November/011913.html> In that mail Lennart mentions that "there is a substantial amount of D-Bus code in PulseAudio now that uses the session bus as a placeholder of a future user bus. All that code I cannot declare official or stable or anything until the user bus is properly introduced." Actually, when the server address discovery service is finished, the clients won't have to care anymore whether the pulseaudio servers are registered on the user or the session bus, so maybe this isn't so critical issue anymore? Of course, as long as the session bus is used, things still fall apart in situations where one user has multiple sessions running. * D-Bus interface for module-device-manager would be nice, but that's not critical and therefore this item shouldn't be on this list... * I will probably remove the object paths from the documentation and review the entire interface to make sure the interface stays usable after that. This removes one unnecessary coupling between the server and client implementations - the server becomes free to rearrange the object path layout whenever it wishes. If someone wants to do something to those items before May, I will happily provide help if needed. I have some code for the first item. -- Tanu Kaskinen
