Hi, these all are very good points. I'm all for changing "reasonably everything" to the "Caps model" - that is, to signatures which are as easy to implement as possible. As far as I can see, this wouldn't compromise correctness much in most cases. Your opinions on this issue are greatly appreciated. Br, Olli Salli Collabora Ltd <div>On 9/20/06, Daniel d'Andrada Tenório de Carvalho <<a href="mailto:daniel.carvalho@indt.org.br">daniel.carvalho@indt.org.br</a>> wrote:<blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> 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* > <<a href="mailto:daniel.carvalho@indt.org.br">daniel.carvalho@indt.org.br</a> <mailto:<a href="mailto:daniel.carvalho@indt.org.br">daniel.carvalho@indt.org.br</a>>> 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 > </blockquote> </div>