W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > August 2015

[web-bluetooth] Should connectGATT() time out or wait until a device is available?

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Thu, 20 Aug 2015 20:52:29 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issues.opened-102234614-1440103948-sysbot+gh@w3.org>
jyasskin has just created a new issue for 
https://github.com/WebBluetoothCG/web-bluetooth:

== Should connectGATT() time out or wait until a device is available? 
==
And if it waits, should that wait be cancellable?

On at least 
[Android](http://developer.android.com/reference/android/bluetooth/BluetoothGatt.html#connect())
 and 
[iOS](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/CBCentralManager_Class/index.html#//apple_ref/occ/instm/CBCentralManager/connectPeripheral:options:),
 if you call "connect" on a device, and the device isn't nearby, the 
call just waits until the device shows up. Bluetooth specifies 
T<sub>GAP</sub>(adv_slow_interval) <= 1.2s as the longest the 
central's supposed to have to wait to connect to a present device, so 
either we could time out the connects, or users could. If we make 
users do it, it naturally solves #31, but we probably want a way to 
cancel the attempt to connect. Right now, unlike in the Android and 
iOS APIs, we only expose [`disconnect()` on the 
`BluetoothGATTRemoteServer`](https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothgattremoteserver-disconnect),
 which is only available once 
[`connectGATT()`](https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothdevice-connectgatt)'s
 promise fulfills.

Right now, I'm inclined to say that `connectGATT()` should hang until 
a device shows up, mention in a Note that 1.2s makes a good timeout, 
and give some way to cancel the connection, maybe by making 
`connectGATT()` fill in `BluetoothDevice.gattServer` synchronously, 
and having folks call `disconnect()` on that.

See https://github.com/WebBluetoothCG/web-bluetooth/issues/152
Received on Thursday, 20 August 2015 20:52:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 August 2015 20:52:33 UTC