[Telepathy] telepathy-glib: TpConnectionManager::protocols is awkward

[Dafydd Harries]

Ar 15/10/2008 am 20:03, ysgrifennodd Murray Cumming:
> On Tue, 2008-10-14 at 19:19 +0100, Dafydd Harries wrote:
> > Ar 14/10/2008 am 17:23, ysgrifennodd Murray Cumming:
> > > On Tue, 2008-10-14 at 13:02 +0100, Will Thompson wrote:
> > > [snip]
> > > > Given that using any D-Bus API inevitably entails using asynchronous
> > > > method calls, I don't see why it's so bad that the ConnectionManager
> > > > proxy object's introspection is asynchronous.
> > > 
> > > The use of D-Bus is implementation and there's no reason to expose that
> > > implementation in (meant to be) higher-level API such as telepathy-glib.
> > 
> > I think that hiding the asynchronous nature of the introspection does a
> > disservice to the user of the API.
> 
> But I think that the introspection should be so fast that it doesn't
> need to be asynchronous.
> 
> >  Users of Telepathy GLib have to understand
> > asynchronous operations in order to be able to use it effectively.
> >  The API has
> > to be asynchronous because (a) D-Bus operations are inherently unbounded in
> > execution time
> 
> Again, why can't a fast reply to introspection just be a requirement of
> connection managers?

The connection manager might be slow to reply for a variety of reasons. It
might be busy with requests from other clients, or the system might generally
be busy. It doesn't have to be very slow for a UI that's waiting for
introspection to be temporarily unresponsive.

Aside from all this, the connection manager might crash while introspecting or
otherwise never reply, in which case the tp-glib client would freeze until the
D-Bus call times out (25 seconds by default in dbus-glib, if I recall
correctly). Of course, this should be rare, but one of the selling points of
Telepathy is that it allows resiliency, and synchronous operation defeats
that.

Now, we might be able to overcome the problem with introspecting connection
managers by making sure that an up-to-date cache is available. But that adds
complexity, and doesn't extend to introspecting other things which are
necessarily dynamic like channels.

> And if it's a fundamental problem with D-Bus, regardless of how quickly
> the connection managers reply, then maybe 
> a) D-Bus is a poor choice for this part of the API.

I'm not sure how else we would communicate this information.

> or
> b) D-Bus needs to be improved to meet your needs for this part of the
> API.

I'm not sure how D-Bus could be improved.

Other concerns aside, the deadlocks inherent to synchronous operations are not
specific to D-Bus, but to any system with request/reply semantics where
entities that receive requests can send requests to those they can receive
requests from.

> >  and (b) it avoids the dedlocks inherent in synchronous
> > operations. Making introspection synchronous would be to pretend that it's
> > somehow different from other Telepathy operations.
> > 
> > I agree that asynchronous APIs are harder to use than synchronous ones, but I
> > think that a lot of this comes down to shortcomings of C (lack of
> > closures/anonymous functions/garbage collection). At least, if there is a
> > nicer way to do async operations in C than that provided by Telepathy GLib
> > then I don't know what it is. Unfortunately, correctness compels us to
> > make our APIs asynchronous, even though it is at a cost of usability.
> > 
> > I basically agree with Havoc's argument[0] that IO should be asynchronous by
> > default (and IO includes D-Bus).
> >  [0] http://log.ometer.com/2008-09.html#7
> 
> Yet there would be a rebellion if gio had only async methods. People in
> the real world sometimes do need to choose simplicity over perfection
> sometimes.

I agree that a synchronous API is useful for gio. Some progams do not need a
responsive mainloop.

My understanding is that we did not provide synchronous interfaces in
telepathy-glib because it was difficult to do so, and we believed that most
applications would need an async API. I'm not a telepathy-glib developer, so
I'm not overly familiar with the details, but if I were writing a Telepathy
client library, I would consider the asynchronous interface more important
than the synchronous one.

> Asynchronous code requires the implementation of a state machine because
> things can be returned in various sequences. The more things that you
> could be waiting on, the more complex that state machine, with more risk
> of a logically stalled (but responsive to the mouse) application, and
> the more difficult it is to make your application work.

I also agree that asynchronous programs are more difficult to write than
synchronous ones, especially in primitive languages like C.

> I can see that I'm not getting anywhere with this line of reasoning, so
> don't bother too much with the discussion in this email. telepathy-glib
> shows that its authors have a very different idea than me of API
> friendliness. Nevermind.

Well, feedback is good. I think in this case, I think it comes down to us
thinking that any increase in friendliness would come at too high a cost of
correctness. At least, if there is a better compromise, we haven't found it
yet.

-- 
Dafydd