Hi Luiz & Marcel, > 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. > We could do something like this, then again, if a tool wants to display the value as a string couldn't they just convert it to a string themselves and simply format it however they like? >> 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. > IMO bluetoothd is not the right place to do this. The high-level API can allow programmers to do some of these conversions, using features of the programming language (like in JavaScript or Python) or by providing additional API functions to perform these conversions (like on Android). Just returning the raw value also makes the development of these APIs easier, especially those that have internal bindings for other platforms such as Windows and Mac that don't necessarily provide the same variant-based data in their Bluetooth APIs (the new Chrome bluetooth APIs are such an example). 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
