Re: [web-bluetooth] Specify a Bluetooth Scanning API.

@Vudentz 
> Im quite concerned with these APIs, it is quite low level which may 
lead us to need to expose scanning intervals which depending on the 
duty cycle can block other traffic such as GATT to happen.

In order to compete with 
[Android](https://developer.android.com/reference/android/bluetooth/le/ScanCallback.html#onScanResult(int,
 android.bluetooth.le.ScanResult)) and 
[Mac](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/CBCentralManager_Class/index.html#//apple_ref/occ/instm/CBCentralManager/scanForPeripheralsWithServices:options:),
 I think BlueZ is going to have to report information with this much 
detail. We can limit the load websites are allowed to put on the 
system, but beacon use cases definitely need to enable duplicate 
events, and seem to need the timing of the last advertisement in order
 to know when things are stale.

If BlueZ doesn't start reporting advertising events, we can infer some
 of this from changes in the Device object, but it's going to work 
less well than other platforms.

>Im also not quite sure how to interpret the aggregation of scan 
response, there could be other advertisements in the meantime shall 
the stacks hold the results until it gets a scan response, for 
requestDevice that may be fine because the API don't except individual
 reports just a device, but here the holding of events may change the 
sequence. Perhaps if this is done via device object, so the scan 
response wouldn't matter and only advertisement would actually cause 
events.

It seems ok to delay the event until after the SCAN_RSP, although 
maybe we'll find use cases that prefer to get both events. The uses 
will have to be ok with whatever Android and Mac do, since it's harder
 to change them.

@krantik 
> How about timeout? Is the call expected to constantly scan or stop 
after sometime? Some of the devices(iOS for example) doesn't 
constantly scan and backs off after some period. Is the same expected 
here?

I could let the UA stop a scan if it's been running "too long". 
Advertisements aren't reliable anyway, so iOS's periodic scan probably
 already satisfies the spec, but I could add explicit wording to allow
 that.

I don't think having folks pass a timeout to `requestLEScan()` will 
help, since iOS will throttle the scan when it wants regardless of 
whether the site passed its own timeout. I expect folks to use 
setTimeout(()=>scan.stop(), xxx) to time out their scans.

> Is the event expected to have parsed data with separate values for 
name etc., or raw data and JS side to interpret it?

Parsed data. See 
https://webbluetoothcg.github.io/web-bluetooth/#fire-an-advertisementreceived-event
 for the parsing. We're nervous about exposing the raw data, both 
because we can't implement that on 
[Mac](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/CBCentralManagerDelegate_Protocol/index.html#//apple_ref/occ/intfm/CBCentralManagerDelegate/centralManager:didDiscoverPeripheral:advertisementData:RSSI:),
 and because some of the fields, like the public addresses hold data 
that we're not sure websites should know.

-- 
GitHub Notification of comment by jyasskin
Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/pull/239#issuecomment-234670081
 using your GitHub account

Received on Friday, 22 July 2016 22:14:43 UTC