Hi Francois, >>> Thanks for your answer Luiz! >> >> Please comment inline in the ml. >> >>> From what I can see, Android and iOS Bluetooth Stack libraries don't >>> claim the device_information service. >>> Could it be possible to make it so that the plugin doesn't block other >>> clients (such as the Web Bluetooth API) from interacting with that >>> service. >> >> That probably a bad behavior in their own because it can only cause >> more traffic as this information can be cached and made available >> without causing any extra traffic, as I said I think we just need to >> expose the extra information over the device API, so we just have to >> add them here: >> >> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note >> that it already contains part of device information) >> > > As these characteristics might not be useful to everyone, I'm not sure > about the benefit of caching all these device_information service > characteristics in Bluez and exposing them to the bluetooth device > object. > From a web developer point of view, I think I want to get back as > quick as possible the bluetooth device object and get characteristics > afterwards when I need to. I am actually fine if we let Device Info services be read by any client. However it is a bit trickier since that means an exception in our code. Also only Device Info will fall ever into this category where you have a system service reading it and where it might be useful for non-system clients. When bluetoothd implement the profile side then we can not have another client trying to mess around with it. Especially when it is security sensitive like HID. 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
