- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Mar 2016 17:03:50 +0000
- To: public-web-bluetooth-log@w3.org
Android, BlueZ, and I think Windows all have persistent instance IDs, but since Mac/iOS doesn't, it's hard to expose it in a spec that needs to be implemented across all of them. These instance IDs also don't expose the actual 16-bit attribute handle in general, and can't be used to look up a characteristic by its handle. If the core Bluetooth spec intends all of its users to call ATT operations directly, why would it provide the GATT procedures in 3.G.4? It seems like they're there specifically so we don't need to map all GATT operations to the ATT level. [`device.gatt.connect()`](https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothremotegattserver-connect) is defined in terms of the GAP Connection Establishment procedures. It's spelled "gatt.connect()" because it connects to a GATT Server, not some other type of server or client that might also be accessible via GAP. (This is hard to follow in the core spec because 3.C.9.3.8.2 just says "The Host shall initiate a connection." without linking to any definition of that in terms of lower level features.) Overall, it looks like the core spec has one or two unnecessary abstraction layers (ATT and maybe GAP), and Web Bluetooth follows Android, iOS, BlueZ, and Windows in omitting them from the user-facing interface. Even if the layers are actually necessary for users, we'd need to get the platforms fixed before Web Bluetooth could depend on them, since browsers are implemented on top of the platforms. -- GitHub Notification of comment by jyasskin Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/221#issuecomment-200443718 using your GitHub account
Received on Wednesday, 23 March 2016 17:03:51 UTC