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

[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?

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.
or
b) D-Bus needs to be improved to meet your needs for this part of the
API.
 
>  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.

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

If I could just get some replies to my outstanding questions then I
could get on with documenting how it could be used.

-- 
murrayc at murrayc.com
www.murrayc.com
www.openismus.com