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 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. Cheers, Arman -- 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
