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

[Murray Cumming]

On Mon, 2008-09-29 at 14:49 +0200, Murray Cumming wrote:
> On Mon, 2008-09-29 at 15:36 +0300, Olli Salli wrote:
> > On Sun, Sep 28, 2008 at 4:10 PM, Murray Cumming <murrayc at murrayc.com> wrote:
> > > TpConnectionManager has a protocols struct field, containing an array of
> > > TpConnectionManagerProtocol, one for each protocol implemented by the
> > > connection manager:
> > > http://library.gnome.org/devel/telepathy-glib/unstable/telepathy-glib-connection-manager.html#TpConnectionManager-struct
> > >
> > > However, it seems that the connection manager must be "introspected"
> > > before this array is non-null. And this seems to be an asynchronous
> > > operation that happens at idle time. So I have some questions:
> > >
> > > 1. Surely this introspection just involves opening the shared library
> > > and calling a function? But, even with a little disk IO to open the
> > > library, this doesn't seem like something that would take a noticeable
> > > amount of time at any significant moment in an application. Why not just
> > > do it whenever necessary instead of making the API complicated?
> > 
> > No, Telepathy Connection Managers aren't shared libraries. They are
> > remote processes, exporting their services through D-Bus. A method
> > call to get the supported properties might take any time up to the
> > D-Bus method call timeout (if there even is any set). Consider eg. the
> > case of a simple not fully asynchronous connection manager, having its
> > mainloop stuck doing eg. a DNS resolve. (Idle, the IRC connection
> > manager, is one such example where this MIGHT happen in rare
> > circumstances). We don't want to freeze the application using the
> > library in this case.
> 
> Shouldn't connection managers just be required to not behave like that,
> instead of letting this detail of the DBus service implementation leak
> out into the public API? They should be able to return this simple list
> incredibly quickly. That would massively simple the API, removing
> opportunies for awkward bugs. Surely that's a worthwhile goal?

I was really hoping for some reply to this.

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