W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > May 2016

[web-bluetooth] Allow requestDevice for all devices

From: Vincent Scheib via GitHub <sysbot+gh@w3.org>
Date: Mon, 02 May 2016 17:19:26 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issues.opened-152599259-1462209565-sysbot+gh@w3.org>
scheib has just created a new issue for 

== Allow requestDevice for all devices ==
Initially the Web Bluetooth specification has required requestDevice 
options to filter the set of devices that will be displayed for the 
user to select from. One argument against allowing developers to 
request all devices be shown is that out of laziness they may often do
 so to the detriment of the user's experience.

When devices do not advertise their services and do not have a 
reliable name that can be used as a filter then there is no way to 
select devices.

One concrete example is this [Bluetooth Rename 
 I made recently (link will break eventually, maybe it will appear on 
[demos](https://github.com/WebBluetoothCG/demos) page eventually). 
This tool uses `generic_access`'s `gap.device_name`, however 
`generic_access` is prohibited from being advertized. It is unknown 
what device names may be already that the user wishes to edit.

I believe other developers will eventually encounter this for devices 
that don't advertise services and have a multitude of names. Though 
this should be a small fraction of use.

This demo currently works in Chrome due to a bug allowing a filter of 
`name: ""` to return all devices. That isn't the right way to solve 
this. I'm not clear on how it should be solved, but would like to 
communicate to developers that they should only ask for all devices 
when they really need to. Only half jokingly:

  filters: [{
    'listAllDevicesEvenThoughItIsAPoorUserExperience': true
  optionalServices: ['generic_access']

Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/234 using your 
GitHub account
Received on Monday, 2 May 2016 17:19:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 17:19:28 UTC