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

[Murray Cumming]

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?

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?

2. Various documentation mentions that the connection manager must be
activated or running. What do these terms actually mean? Is activated ==
running? If so, can we just use one term?

3. Introspection seems to happen soon after activation (for instance,
when we call tp_connection_manager_activate()
http://library.gnome.org/devel/telepathy-glib/unstable/telepathy-glib-connection-manager.html#tp-connection-manager-activate
But the documentation suggests that that function will have no effect if
the connection manager is already activated. So how can I do
introspection in that case?

For instance in a tp_list_connection_managers() callback. I think that
activation happens automatically sometimes after connection manager
instantiation, so I assume that it has already happened in that 
tp_list_connection_managers() callback, though in practice that only
seems true 1 in 10 times that I run my test case.

5. (well, not really a question)
We get the introspection information in a signal handler which runs at
idle time. I have to know that (though it's not documented) so I can
understand why I still have time to connect the signal handler direcltly
after instantiating a TpConnectionManager, without the risk of the
introspection happening before my signal handler is even connected.
The use of idle time is unpleasant, particularly when I am already in an
idle handler (for instance, the tp_list_connection_managers() callback),
and makes it very difficult to get information in a predictable
sequence.



-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com