[Telepathy] Mission Control Spec
raphael at slinckx.net
Wed Nov 1 15:33:19 PST 2006
Good night !
I sense excitement through my powerful telepathy skills. I also
perceive it's because I just finished the Mission Control API Spec
This opens the discussion about specific details rather than the 'big
picture' as it incorporates most of the email exchange's remarks that
were raised a couple of weeks ago.
Beside seeking a general review by everyone involved and an official
blessing for the whole document, here are some more specific bits I
left out because i don't feel confortable with them:
1. Activating the Channel handlers section
Should we block activation for channels belonging to users in the
inside the MC or inside each client being activated ?
2. (NEW) Advertise capabilities
This is a missing interface of the MC spec right now. Because i
didn't totally understand what was discussed.
Here is the ML exchange as a reminder:
>Daf: 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
and that the race/failure model of that API should multiplex ok.
>RobMcQueen:This is just a freebie that you get by putting the info
from the channel
As I understand this, you can advertise capabilities given the
available channel handlers.
For example if there exist a channel handler for type=Text and one
for type=Video, then you advertise
capabilities Text and Video. Is that right ?
3. Unfinished API's for 'syncable settings':
=== (FIXME) Avatars ===
GetAvatar() -> ?
SetAvatar(?) -> void
=== (FIXME) PersonalInfos ===
GetPersonalInfo() -> ?
SetPersonalInfo(?) -> void
Because I don't really know what i should place in the ? mark (simon
can you enlighten me ?)
4. Requesting channels API:
RequestChannelWithAccount(s:chan_type, u:handle_type, s:name,
s:account) -> void
Does this one sounds sane. It's a very simple API to use for apps
that know the type, name and account to invoke a channel on, and
don't care about the underlying details.
I have one question, what if the requested account is disconnected?
In the spec I say that this method then returns an Error. Should the
MC try to connect it instead and then do the foo ?
Or maybe it should trigger a dialog asking for connection ? If this
solution is chosen, how can a dbus API for that work ?
5. More? section
This section contains two bits that I didn't feel would need to be in
the Spec, but as I'm not sure I propose them for review with my short
** Unifying contacts
>Mailing-list: 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
>Me: I think this is the role of galago to merge accounts under a
'Person' and then gather all capabilities that one has with that
person, not the MC role
>Mailing-list: 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.
>Me: A widget library is useful, but i'm not sure wether all apps
should provide configuration for the accounts (rather than a link to
the canonical configuration UI via some dbus activation ?) In any
case you need a widget when adding a contact to one of the account
(to choose which account to add the contact to).
I hope my efforts are useful to someone ! When this spec is accepted
we can all start to finish our MC's for our respective platforms and
then third-party gadgets and applications can use it to unleash the
power of ubiquitous presence with few lines of code.
More information about the Telepathy