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

[web-bluetooth] Consider an event when a device is physically disconnected

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Wed, 24 Feb 2016 19:05:15 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issues.opened-136155982-1456340714-sysbot+gh@w3.org>
jyasskin has just created a new issue for 
https://github.com/WebBluetoothCG/web-bluetooth:

== Consider an event when a device is physically disconnected ==
Calling 
[`BluetoothRemoteGATTServer.disconnect()`](https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothremotegattserver-disconnect)
 disconnects the current Realm and allows the UA to physically 
disconnect if no other Realm is connected. 
[`gattserverdisconnected`](https://webbluetoothcg.github.io/web-bluetooth/#eventdef-bluetoothdevice-gattserverdisconnected)
 in turn reports if the current Realm was disconnected without asking 
to be, but this doesn't say whether the device was 
[revoked](https://github.com/WebBluetoothCG/web-bluetooth/pull/210) or
 the physical connection was lost (and I think we want to preserve 
that ambiguity).

@beaufortfrancois reports that some devices treat physical 
disconnection as a semantic actions, and change their state in 
response, and web pages want to convey that to the user. Is that 
beyond the BT4.0 behavior that peripherals can have only one physical 
connection?

We could add a `.physicallyConnected` attribute to the 
`gattserverdisconnected` event, and use that to distinguish Realm vs 
UA disconnections (treating the UA as including its OS/platform here).
 I don't think we want to let a Realm force the UA to disconnect, 
since that can interfere with other Realms, but the information leak 
from telling a Realm whether other Realms are connected seems small 
enough to accept.

Thoughts?

Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/215 using your 
GitHub account
Received on Wednesday, 24 February 2016 19:05:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:58:20 UTC