Remove Instance IDs

[scheib]

The instanceid attribute currently exists on BluetoothDevice, BluetoothGATTService, BluetoothGATTCharacteristic, and BluetoothGATTDescriptor. The instanceid can be used to

1. Disambiguate multiple instances of objects with the same UUID.
2. Get an object for the instance from the navigator.bluetooth.get* methods (BluetoothInteraction interface).

However, instance IDs may not be exposed on all platform APIs. E.G. See Apple's CBService.

Implementations of Web Bluetooth could manufacture IDs even when the OS API does not provide them to work around this. IDs would need to be invalidated whenever the association can't be maintained, e.g. device disconnection or on Service Change.

Further, the information does not seem essential to a minimum viable Web Bluetooth specification. Multiple service, characteristic, descriptor instances will be returned as unique objects, and applications can assign ID if necessary to them in the same way this specification wound need to on operating systems that do not expose an instance ID.

[scheib]

#52 proposes a subset of removing instance ids: Remove BluetoothInteraction get* Methods

[jyasskin]

I think BluetoothDevice.instanceId is still valuable and implementable as discussed in #32. It's the others that aren't available on Mac/iOS.

[scheib]

https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/CBPeripheral_Class/index.html#//apple_ref/occ/cl/CBPeripheral
appears to have deprecated identifier. Or, am I looking in the wrong place?

[jyasskin]

They moved it into CBPeer but haven't added documentation for CBPeer yet.

[jracle]

@scheib inedeed, as @jyasskin said it has been displaced apparently. I'll ask my (Logitech)Peers here if they know more about that (pun intended..)

[jyasskin]

Do we still need this?

[scheib]

Ok to close, here are my notes:

The usecases in #32 as I understand are essentially:
a) Devices connected to, disconnected, then connected to again should be identifiable as the same device if they are the same device.
b) This concept probably applies to other GATT concepts, but no strong use case is described for why this is valuable.

However in person a while ago Jeffrey and I discussed a particular of 'b':
c) API convenience of connecting to a device and then directly calling navigator.bluetooth.getService/getCharacteristic/getDescriptor to succinctly re-find a known characteristic of interest instead of an app storing the Service/Characteristic UUIDs and searching again for the particular instances of interest. There may also be a performance win here, beyond just additional code, as it avoids round trips.

#52 proposes removing navigator.bluetooth.getService/getCharacteristic/getDescriptor

I believe the minimum viable specification doesn't need to satisfy 'c'. I'm OK with leaving it, but also think it would be acceptable to remove the accessors in #52 unless we come up with another good specific use case in 'b'. Less spec complexity leads to shipping something sooner, and the workaround for 'c' isn't unreasonable I think.