Bug 41323 - Muc D-Bus tube: no way to guarantee that a member is identified before receiving messages from him
Summary: Muc D-Bus tube: no way to guarantee that a member is identified before receiv...
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: TpDBusTube
  Show dependency tree / graph
 
Reported: 2011-09-29 02:19 UTC by Guillaume Desmottes
Modified: 2019-12-03 20:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Guillaume Desmottes 2011-09-29 02:19:23 UTC 
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?
Comment 1 Will Thompson 2012-04-02 07:08:19 UTC 
Can the CM inject a NameOwnerChanged-type signal into the DBus socket? Since it's the CM that invents the unique names, if it squirts

  o.fd.T.PeerConnect(unique name: s, identifier: s, handle: u)

into the dbus connection out to the application then we're gravy.
Comment 2 Simon McVittie 2012-04-02 07:18:41 UTC 
(In reply to comment #1)
> Can the CM inject a NameOwnerChanged-type signal into the DBus socket?

In principle, yes. If it does, it should also prevent Tube apps from faking these signals.
Comment 3 GitLab Migration User 2019-12-03 20:24:54 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/123.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.