[Telepathy] Announce: telepathy-spec 0.99.1

[Alberto Mardegan]

On 09/30/2013 07:56 PM, Simon McVittie wrote:
[...]
> 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)

Yes, though you don't have to remove the signals and method from the 
ChannelRequest interface (unless you really want to avoid duplicate code 
paths).
This is somehow similar to the case of AccountManager.AccountRemoved and 
Account.Removed signals, where you have the signal emitted from the 
parent object as well, to offer different levels of information detail 
(clients who need to use the account will listen to Account signals, but 
those you don't can be content with AccountManager.AccountRemoved).

Here's another two possibilities to shorten the round trip (with 
different levels of evilness :-) ):

1) Use the same API that you have in spec-next, but let smart clients 
know in advance what the CR object path will be, so that they can setup 
the match rules and call Proceed() immediately after calling 
CD.CreateChannel(). In practice, you could allow the client to specify a 
"SuggestedUniqueName" property in the dictionary they pass to 
CD.CreateChannel(), and compose the ChannelRequest object path like 
"<documented-object-path-prefix>/<suggested-unique-name-value>" if this 
results in an available object path (if not, return a different object 
path).
Or even use 
"<documented-object-path-prefix>/<client-bus-connection-name>-<channel-type>-<user-action-time>" 
when available and do not require any additional input from the client.

2) Just forget about the ChannelRequest object, and let 
CD.CreateChannel() return a D-Bus error on failure, or the new channel 
(as currently done by the CR.Succeeded signal) as return value. It just 
needs to be documented that this call might take a long time, so setting 
a longer D-Bus timeout is recommended. Cancellation could be implemented 
as a separate method on the CD, and it could either take the same 
dictionary of requested properties that was passed to CreateChannel, or 
a single string that identifies the request (which could have been 
previously passed to CreateChannel by the client, or computed based on 
the client connection name, channel type and user action time, like in 
the point above).
This would also have the minor advantage that it would be harder for a 
client to cancel a request made by another client (unless they willingly 
talk to each other and share the CR details).

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

Right, but as you said below, the latter drawback can be reduced if the 
clients only subscribe to the CR signals when needed; and besides, in 
the typical case where we really care about the performance down to the 
millisecond, we probably won't have more than 2 clients running at the 
same 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.

It might make the development of simpler clients a bit more complicated, 
but it would indeed address the issue.

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

Right, though it could be solved if the client was a bit careful. Like:
- if owning the GApplication name fails -> quit
- if owning the Client name fails -> retry

Apart from the clients, do you think that the ChannelDispatcher, 
AccountManager and the connection managers would need some deeper 
changes to cope with living in a bus which is not the session bus, or 
could it safely work with just minor changes?
If the latter, there might be some value in trying to get them to be 
bus-agnostic, even though in practice it might turn out that the feature 
is never used.

(so, if someone really wanted to put telepathy in a separate but, he 
would "only" need to care about the clients)

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

Absolutely. I wrote this because I think that the D-Bus server was 
rather inefficient with message dispatching when many clients were 
connected (maybe it was linearly going through all the match rules 
installed), but now I don't even remember if I actually checked this or 
just imagined it. :-)

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

Right, and I think that the most reasonable place for this trivial 
session-bus service would still be inside MC, since the typical 
telepathy client will talk to it shortly afterwards.

Ciao,
   Alberto