bzr-dbus should not require a separate daemon to broadcast notifications

Bug #194251 reported by James Henstridge on 2008-02-22
Affects Status Importance Assigned to Milestone

Bug Description

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.

Related branches

James Henstridge (jamesh) wrote :

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).

James Henstridge (jamesh) wrote :

I've put together a pair of branches that implement (4), and make "bzr dbus-broadcast" use those signals. This should offer equivalent functionality and provides a basis for implementing the remainder.

James Henstridge (jamesh) wrote :

My "~jamesh/bzr-dbus/kill-broadcast-daemon" branch completes these changes, doing the following:
 1. moves the URL mapping code to LanGateway
 2. makes Activity.advertise_branch() and Activity.announce_revision_urls() send a DBus signal directly.
 3. makes LanGateway listen for Revision signals from any source.
 4. removes the Broadcast class and associated code.

This maintains compatibility with the UDP broadcast protocol, but changes the DBus protocol seen locally (so computers with the new and old bzr-dbus installed can talk to each other). It also means that the URL mapping is only done when transmitting revisions over the network: local branches will be announced with unmapped URLs.

James Henstridge (jamesh) wrote :

bzr-gtk has now been updated such that it functions correctly with both the trunk version of bzr-dbus and my modified version. So there are no longer any concerns about breaking bzr-gtk.

  • unnamed Edit (307 bytes, application/pgp-signature; name=signature.asc)

On Di, 2008-04-01 at 15:30 +0000, James Henstridge wrote:
> bzr-gtk has now been updated such that it functions correctly with both
> the trunk version of bzr-dbus and my modified version. So there are no
> longer any concerns about breaking bzr-gtk.
In fact, doesn't bzr-gtk break without this patch applied to bzr-dbus ? :-)


Jelmer Vernooij <email address hidden> -
Jabber: <email address hidden>

James Henstridge (jamesh) wrote :

bzr-gtk should work fine with or without this bzr-dbus patch. The bzr-gtk patch I made just changed it from listening for "Revision" signals from one particular source (the broadcast daemon) to listening for signals from all sources. If it is just the broadcast daemon sending signals, then bzr-gtk will still see them.

Jelmer Vernooij (jelmer) wrote :

Marking fix committed as James has a working patch for this.

Changed in bzr-dbus:
status: New → Fix Committed
Jelmer Vernooij (jelmer) on 2011-05-18
Changed in bzr-dbus:
status: Fix Committed → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments