[Telepathy] Properties of D-Bus MUC tubes

[Alban Crequy]

Hi,

I would like to define whether Telepathy D-Bus MUC tubes have some
properties and document it, so that application developers who want to
use Telepathy Tubes can design their interfaces properly.

Resources:
http://telepathy.freedesktop.org/wiki/Tubes
http://people.collabora.co.uk/~danni/telepathy-book/sect.tubes.dbus.html

Message filters
---------------
Gabble and Salut deliver a D-Bus message to the application only if the
contact is one of the right recipient (either message sent to that
contact or broadcast D-Bus signal). It is different for 1-1 D-Bus
tubes: in this case everything is delivered. See message_received in
src/tube-dbus.c.

Total ordering
--------------
It is guaranteed by Gabble because it use a MUC server, so the server
decides the order of the messages, and everybody receive the messages
in the same order.

For Salut, I think it is guaranteed by the clique protocol and the
reliable multicast protocol. Sjoerd, can you confirm?

When a broadcast signal is emitted, does the sender receive his own
signal? If not, it would break the total ordering (the application
cannot know whether its messages are before or after others' messages).

If one day we implement peer-to-peer connections between the
participants of the D-Bus MUC tube to save the server's bandwidth, the
total ordering may be reconsidered.

Message loss
------------
No message loss on Gabble thanks to the centralised MUC server.
Depending of the MUC server, you can receive messages which were
emitted before you join the D-Bus MUC tube (backlog).

No message loss on Salut thanks to the reliable multicast protocol.

Ordering in membership change by DBusNamesChanged
-------------------------------------------------
Each participant is informed of changes in the tube's membership by the
D-Bus signal DBusNamesChanged. It is emitted in the bus used by
Telepathy (not inside the D-Bus tube).

Does all participants receive the changes of membership in the same
order?

Atomicity in membership change by DBusNamesChanged
--------------------------------------------------
The signal DBusNamesChanged can contain several new members or removed
members. Does all participants receive the same atomicity? Are they
grouped in the same manner?

At least the ones who joins don't get the same DBusNamesChanged signal
since they are informed of all the others' presence.

Ordering between membership change by DBusNamesChanged and messages
-------------------------------------------------------------------
If a participant emits continuously a D-Bus signal in the D-Bus tube
and at some point is informed of a new member by DBusNamesChanged, it
cannot know which messages are received and which messages are not. I
don't know if the Connection Manager can know, but the application
cannot because the signal DBusNamesChanged and the signals emitted in
the tube are not on the same bus, hence not on the same socket, so no
ordering. It is the same problem when a new member joins the tube.

We could implement a bus driver (such as org.freedesktop.DBus or
similar, and messages to the bus driver would be local only) to have
the ordering: the equivalent of DBusNamesChanged/NameOwnerChanged would
be emitted in the D-Bus tube bus and not in the session bus used by
Telepathy.

But in the case of Gabble with a MUC server, the server can send
messages from the past (the backlog), so it is more difficult.

Regards,
Alban