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. I prefer we keep the Value property as array of bytes. We should always expose the real value information for all characteristics. This is especially important for custom services. The one thing I always wanted is a string representation of the Value property as a second property. That way some clients and tools that only need to display the value can rely on bluetoothd giving it a nice translated string. >> 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. The problem is that values are include also types of what their content is. Being it a temperature value, percentage or some other value. Regards Marcel -- 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
