Return-Path: MIME-Version: 1.0 In-Reply-To: References:

From: =?UTF-8?Q?Fran=C3=A7ois_Beaufort?= Date: Mon, 5 Oct 2015 13:23:15 +0200 Message-ID: Subject: Re: Disabling deviceinfo plugin on chromebooks? To: Marcel Holtmann Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" Content-Type: multipart/alternative; boundary=001a113f21522829a9052159be9e List-ID: --001a113f21522829a9052159be9e Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann wrote: > 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. > > That would be awesome actually! 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. > > That makes sense. Thank you Marcel! > Regards > > Marcel > > --001a113f21522829a9052159be9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann <<= a href=3D"mailto:marcel@holtmann.org" target=3D"_blank">marcel@holtmann.org= > wrote:

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 caus= e
>> more traffic as this information can be cached and made available<= br> >> 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.githu= b.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<= br> > afterwards when I need to.

I am actually fine if we let Device Info services be read by any cli= ent. However it is a bit trickier since that means an exception in our code= .

=C2=A0

That would be awesome actually!

=C2=A0

Also only Device Info will fall ever into this category where you have a sy= stem 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 c= lient trying to mess around with it. Especially when it is security sensiti= ve like HID.

That makes sense. Thank you Marcel!=C2= =A0

=C2=A0

Regards

Marcel

--001a113f21522829a9052159be9e--