[web-bluetooth] Redesign access to advertising data for a single device.

scheib has just created a new issue for 
https://github.com/WebBluetoothCG/web-bluetooth:

== Redesign access to advertising data for a single device. ==
Current spec for access to the advertising data of a single device 
appears as:

```
interface BluetoothDevice {
  readonly attribute BluetoothAdvertisingData adData;
  ...
}
interface BluetoothAdvertisingData {
  readonly attribute unsigned short? appearance;
  readonly attribute byte? txPower;
  readonly attribute byte? rssi;
  readonly attribute BluetoothManufacturerDataMap manufacturerData;
  readonly attribute BluetoothServiceDataMap serviceData;
};
```

However, as discussed on 
https://code.google.com/p/chromium/issues/detail?id=568137 (ortuno & 
jyasskin) this is limited in many ways:

- You have to be actively scanning to get the TxPower and the RSSI
- Many devices don't advertise if they are connected to.
- [comment 
6](https://code.google.com/p/chromium/issues/detail?id=568137#c6) 
details on RSII updates from Adv packets and connected device polling.

> We could safely let web sites "scan" for devices they already have 
access to, which would let them opt into the increased power use and 
get advertising data updates. I think we'd change the .adData field 
into a "watch" function and event. Thoughts?


This issue is distinct from issue [Let websites scan for nearby 
advertisements](https://github.com/WebBluetoothCG/web-bluetooth/issues/191)
 which would scan for all advertisements. Though, perhaps if #191 is 
solved this issue may be omitted as a subset of what could be done 
scanning for all AD packets.

Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/212 using your 
GitHub account

Received on Thursday, 4 February 2016 20:41:23 UTC