[Telepathy] Change proposal to Connection.Interface.Capabilities

[Daniel d'Andrada Tenório de Carvalho]

Hi all,

First of all, thanks for your attention, Olli.

I agree with you when it comes to ease of implementation. It's a pain to 
handle complex D-Bus signatures in C, for instance. What I'm trying to 
do with that change proposal is to make Telepathy a little more 
consistent, more coherent.

What are we standing for? Simple signatures compromising correctness to 
favor ease of implementation or the opposite instead? Because, 
currently, Telepathy stands for both of them (or none, depending on your 
point of view).

Connection.Interface.Capabilities interface seems to be on the "ease of 
use" side. But let's take a look at, for instance, PresenceUpdate signal 
from Connection.Interface.Presence interface. It has this intimidating 
(or beautiful) signature:

a{u(ua{sa{sv}})}

This is clearly not easy to construct, handle or iterate over. If we 
were to favor the "ease of use" side, this signature should be 
simplified (following the Capabilities interface style) to:

a(uusa{sv})

So, Connection.Interface.Capabilities is on the "ease of use" side and 
Connection.Interface.Presence is on the "correctness" side.

What side are we taking?

Hope you guys take some time to think over it.

Regards,
Daniel d'Andrada T. de Carvalho - INdT

ext Olli Salli wrote:
> Hi,
>
> I'm afraid I don't see much benefit in the change. It just makes the 
> signals harder to construct and iterate. However, some clarification 
> to the spec could be added regarding the issue, if it's misleading.
>
> Br,
> Olli Salli
>
> On 9/18/06, *Daniel d'Andrada Tenório de Carvalho* 
> <daniel.carvalho at indt.org.br <mailto:daniel.carvalho at indt.org.br>> wrote:
>
>     Hi everyone,
>
>     The some method signatures of the current
>     Connection.Interface.Capabilities are looking somewhat crude.
>
>     They currently use a tuple (contact_handle, channel_type,
>     type_generic_flags, type_specific_flags).
>
>     I'm proposing using (contact_handle, array(channel_type,
>     type_generic_flags, type_specific_flags))
>     since each handle may advertise several channel types.
>
>     The current specification "just works", of course, but its simplistic
>     approach can be an issue (e.g. misleading).
>
>     Attached to this e-mail is a patch to solve that.
>
>     Regards,
>     Daniel d'Andrada T. de Carvalho - INdT
>