[Telepathy] Proposed standard MC API

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Aug 2 06:06:24 PDT 2007


On Wed, 01 Aug 2007 at 15:31:32 +0100, George Wright wrote:
> FindAccounts ( a{sv}: account_data ) -> ao
> 
>   Returns all accounts whose account data contains the search query.
> 
>   An empty array should return all possible accounts.

Please explicitly say that the account_data is the same as for Telepathy's
RequestConnection() parameters.

> ConnectAll ( ) -> nothing
> 
>   Requests all accounts go online with the default presence.

... all enabled accounts, presumably?

> UpdateParameters ( a{sv}: account_data ) -> nothing
> 
>   Update the account parameter dictionary.

Is this meant to be: for each (key, value) pair in account_data,
set that key in the account parameters to that value, leaving any keys
not mentioned unchanged?

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.

> 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?

> + Presence States (enumerated type):
> 
> 0 Unset
> 1 Offline
> 2 Available
> 3 Away
> 4 Extended Away
> 5 Hidden
> 6 Do Not Disturb

This is Telepathy's Connection_Presence_Type enum, except with the
addition of "Do Not Disturb". Can't we just add
Connection_Presence_Type_Do_Not_Disturb to Telepathy and recycle that
enum as-is in MC?

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.

> - 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.

Regards,
	Simon


More information about the Telepathy mailing list