[Telepathy] mission control API

Eitan Isaacson eitan at ascender.com
Tue Oct 10 12:18:21 PDT 2006


I would add two more, IMHO:

 * Unifying contacts:
It would be cool if there was some correlation between identical
contacts. This could allow fallbacks to different CMs depending on the
contact's availability. A simple use case, I want to message Beth, my
priorities are: Jabber, MSN, SMS. This means that I will attempt to
reach her in that order, depending on availability. The CM needs to
magically unify all these contacts, and needs to give the user a way to
alter the preferred methods of communication.

 * Widget library:
For desktop MCs it would be nice if they provided a shared library with
a variety of useful widgets in their respected toolkit (QT/GTK+), that
would allow any program to display account settings, list CMs and such
with a unified look. It will use the API you guys proposed. A simple use
case: A user expects to be able to edit his accounts settings in the
roster window (which is not part of MC), the roster program (ie.
Gossip), could simply display the same thing you would see in the MC's
capplet.


On Tue, 2006-10-10 at 16:28 +0100, 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.
> 
>  - Unifying presence across accounts
> 
>    By this, I mean that mission control tries to keep all your accounts in a
>    consistent state. If you tell mission control that you want to go online,
>    it will bring all of your accounts online. If you are idle, it will set all
>    your accounts away. If a connection falls offline due to a network error,
>    it will try to reconnect it. It can also signal an error to a UI if an
>    account fails to authenticate. (I'm thinking in terms of supporting the UI
>    Gossip currently for indicating that an account failed to connect.)
> 
>    It may be possible for mission control to use NetworkManager to know of
>    network connections/disconnections and connect/disconnect connection
>    managers as appropriate.
> 
>    On second thoughts, perhaps the client or a presence applet should be
>    responsible for auto-away.
> 
>    In terms of API, I think a simple SetPresence call / PresenceChanged signal
>    should cover most requirements.
> 
>  - 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.
> 
>    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. We could try and
>    get KDE and Gnome to use the same storage format for accounts, but
>    currently this has drawbacks: e.g. storing account information in GConf
>    allows for notifications when the information changes. If a freedesktop.org
>    standard for configuration storage emerges, then we can consider to
>    migrating to it at that point, I think.
> 
>    For editing accounts:
> 
>    CreateAccount(s: name)
>    SetAccountProperty(s: account, s: property, v: value)
>    GetAccountProperty(s: account, s: property) -> v
>    DeleteAccount(s: name)
> 
>  - 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?
> 
>  - Advertise capabilities
> 
>    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 think this covers the major areas of functionality. Did we miss anything?
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20061010/f73fbb86/attachment.pgp


More information about the Telepathy mailing list