[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
Regards,
Rob
More information about the Telepathy
mailing list