[Telepathy] mission control API

[Tobias Hunger]

On Tuesday 17 October 2006 19:58, Robert McQueen wrote:
> As a trivial example, Gabble has no "require-encryption" because it
> doesn't support TLS, but instead you must use "old-ssl" to connect with
> the deprecated SSL support.

No problem at all: From Houston's point of view Gabble just can not do 
encryption. "old-ssl" is not in the spec, so Houston will just not recognize 
that setting. Since it is marked "optional" in the gabble CM this should not 
matter too much. In that regards Gabble is a broken CM which we must make 
sure to handle gracefully... I am sure there will be more of those soon;-)

In my opinion telepathy should be more expressive when describing the the CMs. 
A application must be able to get a pretty complete impression of the 
capabilities of the CMs installed or the whole concept of telepathy does not 
make sense: Why should you use a generic interface to a set of functionality 
if you must code for one specific CM anyway?

<snip>
> An MSN connection manager 
> might support logging in via HTTP; another might not.

How can an application find out whether a CM can do so or not? I have not seen 
any parameter to enforce this in the spec yet.

> If you've configured an account against a connection manager assuming
> the availability of a certain set of options, it's a bug (as in, if any
> of the options were necessary to establish a working connection, you
> very likely won't be able to connect) to try and pass that same
> configuration to a different connection manager implementing the same
> protocol. This sucks a bit but I don't see a very clear way around it.

There should be a way for an application to query a CM for its capabilities. 
Interesting capabilities would e.g. be encryption supported or not (using 
which algorithms), authentication types supported and things like support for 
advanced features like sending files, etc.

Yes, I know: Whether all the advertised capabilities are really useable on any 
given connection does depend on the server we are using and the capabilities 
of the peers, etc. But there is no sense in using any CM locally that does 
not support sending files (or streaming video or whatnot) if that is what the 
user wants to do in the first place. We will need to use one CM that actually 
can do the thing that the user wants to do, connect that and then figure out 
whether it is actually doable with the servers and peers involved. 

I think a API to advertise these capabilities is still missing on the CMs. 
Connecting one CM and only finding out afterwards that something does not 
work is just to time consuming (but of course unavoidable in some cases).

Best Regards,
Tobias Hunger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20061018/254e498b/attachment.pgp