- From: Julien Racle via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Jul 2016 07:37:00 +0000
- To: public-web-bluetooth-log@w3.org
@jyasskin thanks for the clarification, it makes sense to me no pb. Point is that as of today many developers (not web developers I agree) are used to APIs that clearly discriminate retrieving connected peripherals ([Android](https://developer.android.com/reference/android/bluetooth/BluetoothManager.html#getConnectedDevices(int)), [iOS](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/CBCentralManager_Class/index.html#//apple_ref/occ/instm/CBCentralManager/retrieveConnectedPeripheralsWithServices: ), which are closer to underlying implementation, and we are trying here to mix 2 concepts into 1 : devices connected to the system versus nearby devices. At a UX standpoint, suppose I want to retrieve my connected BLE HID devices (e.g. my MX Master mouse), and don't want to be proposed the one from my neighbor, how sould I know which device to select? As regards discovery, couldn't then we introduce requestLEScan() [from day 1](https://github.com/WebBluetoothCG/web-bluetooth/milestones), so that we'd use it to discover nearby devices. I admit that if we don't have it at the beginning, then requestDevice() also has to perform discovery. My fear is that we might not want to change its behavior once we ship first milestones. Thanks ! -- GitHub Notification of comment by jracle Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/255#issuecomment-235821907 using your GitHub account
Received on Thursday, 28 July 2016 07:37:09 UTC