- From: Luiz Augusto von Dentz via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Jul 2016 11:17:11 +0000
- To: public-web-bluetooth-log@w3.org
@jyasskin > In order to compete with Android and Mac, 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. BlueZ is used in very different systems as Android, it is quite common to have multiple applications using the API in parallel, perhaps we could compare it to Mac but looking at its API it seems to be very similar to the kind of access BlueZ offers with StartDiscovery combined with SetDiscoveryFilter. Btw, it is already possibility to enable duplicated reports, in that case the RSSI property is emitted every time we receive a report from the peripheral, similar to what is stated in the Mac documentation. > 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. Well we do wait for the scan response so the applications can see the device name, etc, which is quite convenient for requestDevice but it perhaps wouldn't be for requestLEScan, anyway as long as it not strictly forbidden I guess we can live with that. Btw, we also have to keep in mind there could be peripherals connected which makes requestLEScan even less reliable as it cannot use very high scan duty cycle in such cases. -- GitHub Notification of comment by Vudentz Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/pull/239#issuecomment-234926629 using your GitHub account
Received on Monday, 25 July 2016 11:17:22 UTC