[Telepathy] Announce: telepathy-spec 0.99.1

[Simon McVittie]

On 30/09/13 13:33, Alberto Mardegan wrote:
> About especially the "reduce complexity" point, I have some concerns
> about the ChannelRequest object.

This is a good time to raise this sort of thing. At the moment I'm
trying to bring Mission Control up to spec and telepathy-glib 0.99.2
before we do any more spec or telepathy-glib changes, but once we have
everything compiling against the same snapshot, we can continue to tidy
up the D-Bus API.

> You might remember that in Maemo times
> I added an RequestChannel interface to the Account object:
...
> While it is indeed arguable whether the Account object is the best place
> for this interface, the advantage of the interface we had in Maemo was
> that it required less D-Bus traffic to accomplish the same goal because
> the operation result was delivered on the same interface,  and there was
> no need to wait for the ChannelRequest object to be created and
> subscribe to its signals (which also adds the need for the Proceed()
> method found in the newer ChannelRequest object).

Am I right in thinking that the closest equivalent if using
ChannelDispatcher instead of Account would be something like this?

- delete ChannelRequest.Succeeded(), CR.Failed(s, s), CR.Proceed()
- add ChannelDispatcher.RequestSucceeded(o), CD.RequestFailed(o, s, s)

(where the object paths are the path of the CR and the other arguments
are carried over)

If so: cost:

- no way to tell a CR has been invalidated without watching the CD's
  signals (valid, but somewhat odd)
- anything that is interested in *any* CR is woken up by signals for
  *every* CR (it can't use arg0path, because that'd require bringing
  back Proceed() to avoid the same race condition)

and benefit:

- one less Proceed message per channel request
- one less pseudo-round-trip (return ChannelRequest from MC to client,
  client calls Proceed) per channel request.

Proceed is currently spec'd to never fail (although MC has never
implemented this 100% - fd.o #21036), so it isn't really a round-trip -
it can be "fire and forget". The "return ChannelRequest, call Proceed"
path is basically equivalent to a round-trip, though.

> So, to keep it short, what do you think about sacrificing a little of
> the API beauty for avoiding roundtrips (and, in general, to minimize
> D-Bus traffic)?

As a general principle: "yes if the benefit exceeds the cost".

My opinion on this specific example depends how long the
pseudo-round-trip actually takes in practice, and how long, overall, it
actually takes to request a channel. Text channels are often trivial to
set up (in message-oriented protocols like XMPP/IRC/SMS, you don't have
to do any per-Channel work at all), so the D-Bus calls might take longer
than the actual work; but a clever UI can let you start typing a message
before there's actually a channel, so it doesn't really matter much. For
all other non-deprecated channels (calls, file transfers, tubes) I would
expect the time to call Proceed to be tiny when compared with the
network latency, etc. of doing the actual work.

I assume the implementation you have in mind would be for clients that
are currently requesting a channel to add a temporary match rule for
RequestSucceeded and RequestFailed, rather than for every client that
might conceivably request a channel to add those match rules for its
whole lifetime? If so, we can assume that "every client interested in a
CR is woken up" is a non-issue, because the common case will be one CR
at a time.

One alternative design would be to require that the requesting client is
a Client (probably requiring it to pass its bus name to the
Create/Ensure call), and call something analogous to RemoveFailedRequest
on it instead of using signals.

> On a side note: would it be possible to move telepathy to its own bus,
> (so that it could be given higher/lower priority depending on the device
> profile) or would that require changes to the spec?

It would be possible, but I'm very cautious about introducing parallel
buses, because as soon as you have parallel buses, you get undefined
message ordering, and lose atomicity of name ownership etc. (e.g.
Empathy would own a Client name on the Telepathy bus, and a GApplication
name on the session bus).

If we leave it undefined whether "the Telepathy bus" is the same as the
session bus or not, I expect we'll have a lot of code that, in practice,
is never tested (and thus doesn't work) with two distinct buses. If we
define them to be always separate, then we always have the complexity of
managing an extra dbus-daemon, without necessarily getting much benefit
from it (in the "happy path" case where the session bus is not overloaded).

Similar to the other thing, I'd like to see something more quantifiable
than "it might hypothetically be a problem" before adding complexity.

It might be the case that doing something cleverer with D-Bus priorities
(e.g. the unfinished kdbus, having the dbus-daemon poll high-priority
connections below low-priority ones, or just applying a lot of renice(1)
to low-priority proceses) can solve whatever the underlying problem is
without increasing application-level complexity.

Based on my experience with maintaining libdbus (and in particular, the
undocumented mess that is dbus-launch), if we do have a separate
Telepathy bus, I'd like to define a single way to locate it (probably
"ask a trivial session-bus service on startup"), and heavily discourage
any alternatives. Definitely no tricks with X11 windows or environment
variables...

    S