[Telepathy] Proposed standard MC API

[George Wright]

On Thursday 02 August 2007 14:06:24 Simon McVittie wrote:
> Please explicitly say that the account_data is the same as for Telepathy's
> RequestConnection() parameters.

Already says that in the XML spec.

> ... all enabled accounts, presumably?

Indeed. I'll amend that.

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

Undecided. I was thinking along the lines you're saying - only change those 
keys which are mentioned and leave those not mentioned still there with the 
old values. Is there any reason for wanting to do it another way?

> The parameters and enabled state have a "get" method but no change
> notification. Is this deliberate or an omission?

I think it would be wise to add a signal which is emitted when accounts are 
enabled. Is there any reason why we would want a change notification for 
parameter changes?

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

Is there any point in adding additional bus traffic for change notifications 
when we could just listen to the CM?

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

Indeed, this has been discussed and I think we should change it to a unified 
method, SetPresence (u, s).

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

You'll have to speak to Rob about that. :)

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

If they are poorly supported by bindings it would probably be unwise to use 
them extensively.

Regards,

George

-- 
George Wright, http://www.gwright.org.uk
Collabora Ltd - http://www.collabora.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20070802/a208205e/attachment.pgp