Currently bzr-dbus relies on a notification daemon to send its broadcasts (bzr dbus-broadcast). It should be able to run without such a daemon, instead using the session bus directly to send the messages. Below is a sketch of how this could work.
1. At present, when a branch changes the "announce_revision" method is called on the broadcast daemon. The broadcast daemon then issues a signal (annotating it with additional URLs). Instead, the signal could be emitted directly. There is code in bzr-avahi that does this.
2. The "bzr commit-notify" command listens to "Revision" signals from the broadcast daemon and shows notification bubbles. It could instead listen for the signal from any source to pick up direct signals.
3. The "bzr lan-notify" command forwards local revision announcements to the local network and vice versa. This should be pretty much the same without the broadcast daemon. What is missing is annotating the broadcasts with extra URLs. For this, I'd suggest that lan-notify should keep track of the URL map and perform the mappings on URLs before broadcasting them on the LAN.
This will work fine if lan-notify is started before "bzr serve", since it will see the add_url_map()/remove_url_map() signals. However, if it is started afterwards, it will miss the add_url_map() signal. To handle this case, I'd suggest making lan-notify send out a "find_servers" signal on startup, which would cause any existing servers to resend the appropriate add_url_map() signal.
4. The above requires the "bzr serve" process to be able to respond to DBus signals while it is running. I've got code in bzr-avahi to run the glib mainloop in a thread that could be adopted here. If this code is adopted, it'd be good to make it hookable so that bzr-avahi shares the mainloop thread with bzr-dbus.
A few benefits of this include:
* gets rid of a daemon, and the need to install dbus activation foo.
* the set_rh call no longer needs to wait for a dbus method response -- it can send the signal and be done with it.
* since "bzr serve" instances are connected to the session bus, we can detect when they die unexpectedly: a org.freedesktop.DBus.NameOwnerChanged signal will be sent. This would allow us to remove stale URL mappings.
* If no listeners are active, the code sending DBus signals will only wake the session bus.
This design would solve bug 105000 (bazaar dbus plugin aborts commit one the broadcast service crashes) since "bzr commit" no longer needs to wait for a DBus message reply.
It'll most likely fix bug 107169 (Failed to execute dbus-launch to autolaunch D-Bus session) too since it no longer relies of DBus service activation. The same goes for bug 125425 (dbus plugin falls over when /usr/bin/bzr not found).