[Telepathy] Proposed standard MC API
George Wright
george.wright at collabora.co.uk
Thu Aug 2 06:20:21 PDT 2007
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
More information about the Telepathy
mailing list