[Telepathy] mission control API

[Tobias Hunger]

Hi Daf!

Sorry for answering only now, I was at the Linux World in the Netherlands and 
had very limited connectivity for the last two days. I put in the Houston 
equivalents to the groups of functionality you propose in all uppercase:-)

On Tuesday 10 October 2006 17:28, Dafydd Harries wrote:
> I spent a bit of time with Raphaël at Boston thinking about what mission
> control needs to do, and what API it needs to provide.

ACCOUNTMANAGER:

>  - Unifying presence across accounts
<snip>
>    On second thoughts, perhaps the client or a presence applet should be
>    responsible for auto-away.

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.

I do consider online/offline/presence state as part of the account settings, 
which is why this sails under the heading of "AccountManager" in Houston.

>  - Manage accounts
>
>    Mission control must be able to read your account information. It is
> useful if a graphical account settings editor can use mission control to
> add, edit and remove accounts.

I fully agree.

>    While such an API would allow, e.g. a KDE Telepathy accounts editor to
> edit accounts on a Gnome mission control, this does not necessarily mean
> that KDE and Gnome share account information, which is a shame.

Yes, it would be so cool if gnome-keyring and kwallet would be able to agree 
on one share DBus Interface!

<snip>
>    For editing accounts:
>
>    CreateAccount(s: name)
>    SetAccountProperty(s: account, s: property, v: value)
>    GetAccountProperty(s: account, s: property) -> v
>    DeleteAccount(s: name)

I left out a method to list all known accounts.

COMPONENTMANAGER:

>  - Launch channel handlers
>
>    I don't think this requires any API unless we're intersted in being able
> to configure MC to suppress incoming channels. We could make MC ignore
> incoming channels from contacts on the deny list for instance, but perhaps
> this behaviour belongs in the client. Yesno?

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

>  - Advertise capabilities

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

>    Tell online accounts that we are able to e.g. receive video calls. I
> think this can look the same as the AdvertiseCapabilities method on
> connections, and that the race/failure model of that API should multiplex
> ok.

I have to admit that so far I did not think too hard about this issue, but 
your suggestion sounds OK.

> I think this covers the major areas of functionality. Did we miss anything?

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.

It is further no use to require a application programmer to remember 
that "gabble" == "jabber" ;-)

Best Regards,
Tobias
-------------- 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/20061013/6e6b4d1e/attachment.pgp