[Telepathy] mission control API
tobias at aquazul.com
Fri Oct 13 02:44:05 PDT 2006
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.
> - Unifying presence across accounts
> 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
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!
> 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.
> - 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
> 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
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?
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
It is further no use to require a application programmer to remember
that "gabble" == "jabber" ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20061013/6e6b4d1e/attachment.pgp
More information about the Telepathy