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

[Simon McVittie]

On Sun, 28 Sep 2008 at 15:10:45 +0200, Murray Cumming wrote:
> http://library.gnome.org/devel/telepathy-glib/unstable/telepathy-glib-connection-manager.html#tp-connection-manager-activate

Please use http://telepathy.freedesktop.org/doc/telepathy-glib/ (or a
current source tarball or git checkout that you've compiled) for reference.
library.gnome.org has an outdated version of telepathy-glib... I've filed a
bug but not had time to follow up on it.

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

I think what you're missing is that the canonical source of CM info is a
D-Bus method call, which takes time, crosses process boundaries, etc.
and so is done asynchronously. We never dlopen a library and look at it,
because CMs are processes, not libraries (they can be written in any
language with a D-Bus implementation).

There are two possible sources of CM info, see
http://telepathy.freedesktop.org/spec.html for the gory details...
here's a summary.

The connection manager itself is the canonical source - you ask it over
D-Bus by calling methods on the ConnectionManager interface. This
requires the connection manager process to be running, but D-Bus service
activation can be used to ensure this (we just call methods on it, and
the D-Bus daemon will arrange for the CM to be run so it can reply).

TpConnectionManager does this automatically whenever it notices the
connection manager is running, but won't automatically run the CM just
for that (unless the library user asks it to - an account creation UI
would be entirely justified in doing this, for instance).

The other source of information is the ".manager" file. This is a cache
on disk of what answers the CM would give to those method calls, as an
optimization. TpConnectionManager also automatically reads .manager
files.

However, not all CMs can have a correct .manager file. For instance,
telepathy-haze can gain support for random protocols at runtime because
the user installed extra Pidgin plugins, so there's nothing we can
usefully put in the .manager file - whatever we say there, it might be
wrong because of third-party plugins.

(At the moment Haze *does* install a .manager file, but that's a bug. We
only do that for compatibility with old Telepathy infrastructure where
the .manager files were required, and it will go away at some point.)

So:

* TpCM automatically reads .manager files if they exist, without library user
  intervention

* TpCM opportunistically calls methods on CMs if they happen to be running
  anyway, without library user intervention

* Introspection always looks asynchronous (either via idle callbacks or
  D-Bus calls) just to make it vaguely consistent, since the D-Bus calls
  should always be asynchronous in any case

* TpCM doesn't automatically activate CMs that aren't running, unless the
  library user specifically asks it to (to avoid the CPU/memory cost of
  running all the CMs in the world by mistake)

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

The connection manager must be running (adjective). The way to ensure
that it is running is to activate it (verb). I hope I've been consistent
about that; if not, patches welcome.

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

It's done automatically; between the point when introspection finishes
and the point when the CM process exits, the introspected data is
guaranteed to be up to date (it can't change during runtime). So, you
don't need to re-trigger introspection if it has already happens.

(If the CM exits and is run again, re-introspection is probably a good
idea, since it might have different plugins or compile options this time.
I think TpCM does this automatically, though.)

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20080929/de6050dd/attachment.pgp