[Telepathy] connection manager discovery

[Raphaël Slinckx]

Hi !

On Thu, 2006-08-31 at 00:40 -1000, Jimen Ching wrote:
> The spec says the client needs to read a disk file to determine the
> available d-bus connection manager services available.  I'm curious why
> this approach was chosen.  In most modern client-server architectures, the
> client doesn't keep track of which services are available.  I.e. protocols
> like CORBA have directory services where a client can go to query for
> available services.  What advantage is there for the client application to
> maintain a local file of services available at the server?
> 
> Doesn't this approach open up a potential for a misconfigured system where
> the service isn't available, but the file says it is?

AFAIK dbus doesn't provide such a directory mechanism. There is no easy
way to know which service are available other than trying to activate it
and see if it fails because of an unknown service (or maybe you can
probe a service to see if it can be activated).

But the main reason it was done like that, is that the client doesn't
want to launch all available connection managers, ask them for their
required/default paramaters and then shut them down. Imagine if you have
5 connections managers, some might be in a slow-to-startup language it
would be hell.

Then the client would cache the parameters anyway, recreating the same
file as is provided now, but without guarantees it stays in sync with
the connmgrs (or you'd have to implement some clever timestamping and
stuff).

The file we use now is guaranteed to be in sync with the connmgr since
they are installed from the same package with your packaging system.
Reading the file is trivial with every framework capable of reading
key=value files (ini files). And maybe some kind of easy API is/will be
provided with libtelepathy/telepathy-python or whatnot.

I hope this answers your question :)

Raphaël