[Bug 41323] New: Muc D-Bus tube: no way to guarantee that a member is identified before receiving messages from him

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41323

           Summary: Muc D-Bus tube: no way to guarantee that a member is
                    identified before receiving messages from him
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: tp-spec
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: guillaume.desmottes at collabora.co.uk
         QAContact: telepathy-bugs at lists.freedesktop.org


So, I'm working on implementing high level API in TpDBusTubeChannel to accept
and offer the tube.

In the muc case, we have the DBusNames property allowing clients to identify
members of the tube. I'd like to ensure that a member is identified (it's muc
D-Bus name <-> TpContact mapping is known) before we receive any message from
this contact on the tube; saving applications to have to deal with messages
from unknown contacts.

http://telepathy.freedesktop.org/spec/Channel_Type_DBus_Tube.html#Property:DBusNames

But I'm afraid that's currently not possible. :\

When a contact joins the tube, the DBusNamesChanged signal is fired (so this
signal is transmitted using the socket of the session bus). Then let's say we
receive some traffic on the tube from this contact; this message is relayed by
the CM through the socket of the *tube* D-Bus connection.

So we have information travelling on 2 different sockets making any ordering
guarantee impossible!

Furthermore if the client wants to prepare the TpConctact before announcing it
we really need a way to block the tube while it's preparing.

I see different options to approach this problem:

a) Block any traffic on the tube when DBusNamesChanged is fired with at least
one contact added until the handle 'acks' this information and unblock the
tube. Kinda nasty and breaks legacy D-Bus tube apps (but do we care tbh?).

b) Send the DBusNamesChanged information on the *tube* D-Bus connection as
well, using a well known D-Bus API implemented by TpDBusTubeChannel on the
tube.
The CM could call a method ContactAdded(u: handle, s: id, s: dbus-name) or
something and the client returns from this method when he's done preparing the
contact; the tube staying blocked while this method is running.
This looks like a better approach to me and doesn't break legay app: this
method will just fail with NotImplemented.

Thoughts?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.