[Telepathy] mission control API

[Robert McQueen]

Tobias Hunger wrote:
> I want to have a AccountManager in Houston, that can be used to bring accounts 
> online as required. I further want to keep the code in Houston minimal, so I 
> do prefer having a application outside of Houston doing the unifying. It 
> should be trivial to write with a good API for bringing accounts 
> online/offline.

Unifying as in responding to events and then setting the same presence
on all of your connections, trying to reconnect if one signs off, etc?
I'd consider that the job of mission control.

> I do think this requires an API: The user should be able to configure which 
> applications are started in response to which channels.

Hmm... API versus reading configuration directly? If it was API, what
would use the API and make changes? It might end up with a complex D-Bus
API to query static per-system information which a library could just've
read for you.

> Not sure where this belongs... probably into the AccountManager, maybe in the 
> ComponentManager.

ComponentManager; it knows it can handle FOO BAR and BAZ type channels.
It needs to tell each connection with the capabilities interface that
this is the case.

> PROTOCOLMANAGER:
> 
> In the interest of abstraction (yes, I know you do not like that too much;-) 
> I'm implementing a ProtocolManager. It is a really thin wrapper around 
> tapioca-qt that hides the ConnectionManagers from the view of the application 
> programmer. It has a very simple API which allows to query CMs by protocol 
> and has a method to return the "preferred CM" for a protocol. I am pretty 
> sure we will end up with several CMs for each protocol (we are working on 
> open source after all;-) and so there must be a way to configure which one to 
> use.

There's no problem with this in concept, but I must warn you that it has
potential problems. I fully expect we'll end up with more then one
implementation of each protocol before long (particularly if we start
seeing existing multi-protocol codebases exposed as connection
managers). The upshot of this is that options that are valid on one
implementation of a protocol might not be valid on another implementation.

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. Another more XMPP-purist Jabber connection
manager might have "require-encryption" & TLS support, but no SSL. One
manager might have proxy support, another not. An MSN connection manager
might support logging in via HTTP; another might not.

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.

> Best Regards,
> Tobias

Regards,
Rob