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

[Murray Cumming]

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?

> Note that for some connection managers, for which there exists a
> .manager file, no DBus call is actually necessary, just reading that
> file is sufficient (and that can happen synchronously, sure). However,
> for eg. Haze such a file can't be reliably provided, since the actual
> set of supported protocols it supports depends on the underlying
> version of libpurple. Therefore an asynchronous D-Bus introspection is
> always needed.
> 
> >
> > 1.1. It seems that we even need to trigger introspection to get the
> > "cached" information. What is it about real introspection that takes
> > even more time than getting cached data from a file?
> 
> Read above.
> 
> > --
> > Murray Cumming
> > murrayc at murrayc.com
> > www.murrayc.com
> > www.openismus.com
-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com