[Telepathy] Proposed standard MC API

Robert McQueen robert.mcqueen at collabora.co.uk
Thu Aug 2 10:22:55 PDT 2007

Simon McVittie wrote:
>> ConnectAll ( ) -> nothing
>>   Requests all accounts go online with the default presence.
> ... all enabled accounts, presumably?

Probably redundant anyway, given you can achieve the same by just
calling SetGlobalPresence (ONLINE). I'd expect that to only work on
enabled accounts. :)

> The parameters and enabled state have a "get" method but no change
> notification. Is this deliberate or an omission?
> The avatar, display name, presence have no change notification. If
> clients are expected to listen to the CM signals directly for change
> notification of these, please mention that in the documentation for the
> "get" function.

Some of these values are different to the CM's values, certainly the
"desired" avatar and presence is manipulatable independently, and
there's some kind of

>> SetPresenceMessage ( s: message ) -> nothing
>>   Set a presence message on an account.
> Surely you only ever want to set the presence status and the message
> at the same time, with a method (u, s) -> nothing?

Yeah these should be merged.

> Nokia's MC and/or UI appears to map Hidden to "invisible on connections that
> support it, do-not-disturb otherwise" which would also be reasonable.

Yeah, NMC does this; in general MC implementations should make a best
effort to set what was asked for. We could specify the fallbacks for
what presences to set if the requested one is unavailable, it would
probably go like this:

Away: Available
Extended Away: Away, Available
Hidden: Busy, Away, Available
Busy: Available

Or we definitely shouldn't do that because it's a policy decision, and
certain MC implementations might want to be able to do stuff like "never
make me visible if I asked for invisible".

>> - Accounts; enabled, normalised name, display name, etc - do we want to
>>   implement these as D-Bus properties or methods? 
> D-Bus properties are poorly supported by bindings, likely to be hard to
> deal with asynchronously, and don't have change notification. Telepathy
> consistently uses signal/method pairs and I think MC should do the same.

I suppose it's better to stick with what we're doing currently. I
continue to think D-Bus properties are totally useless due to having no
pre-determined readability/writability information. I was half-thinking
we could re-use Telepathy properties, but the general consensus is that
API's a bit awkward, so maybe not.

> Regards,
> 	Simon


More information about the Telepathy mailing list