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

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

From: Vincent Scheib via GitHub <sysbot+gh@w3.org>
Date: Thu, 04 Feb 2016 20:41:20 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issues.opened-131468018-1454618480-sysbot+gh@w3.org>
scheib has just created a new issue for 

== 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 
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 
 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

This archive was generated by hypermail 2.3.1 : Thursday, 4 February 2016 20:41:24 UTC