Hi Arman, On Fri, Jul 25, 2014 at 9:50 PM, Arman Uguray <armansito@xxxxxxxxxx> wrote: > Hi Luiz, > >> Im just wondering why we did not use variant type instead of array of bytes >> for value, imo it seems a better fit since it can be extended with different >> types in host byte order. >> > > I don't think that is such a good idea. Characteristic/descriptor > values are usually meant to be interpreted as a series of bytes > encoding different kinds of data of various lengths based on the > profile (e.g. the first byte is a bit mask, the following two bytes > are a uint16, etc). I think it's better to just leave it as an array > of bytes in the order that it was received from the wire as this is > what clients will expect and the order in which the bytes should be > interpreted will be explicitly specified by the profile In case we know the profile we could go ahead an decode upfront and in case we don't know how to decode we keep the array of bytes inside the variant. > On occasion you have a characteristic value that encodes, for example, > a complete string. Then again, if we put a variant of string as the > value property there, only those clients that know beforehand that the > value contains a string will be able to work with it. If you're > implementing a high-level generic application API, this won't work. Well a variant is a container so it can carry any of those values including string or even an array of strings and I believe it would make things even more simple to a client generic API because it can directly be based on D-Bus variant type that most bindings do already support. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
