Align unique indexes across DeviceInfo and Device Commands (Buttplug v4 Spec)
qdot opened this issue · comments
As of Buttplug spec v2 (and unchanged in v3), when packaging device info during DeviceList/DeviceAdded, we send over arrays of info, from which indexes are assumed.
However, in device commands, we ask for indexes of that info.
With things like Sensor*Cmd and ScalarCmd, this presents multiple problems.
API Creation Difficulty
For both ScalarCmd and SensorCmd, this means that we can have types come out of order, depending on the device configuration order. This means that, for a scalar command, you could have a vibrator, then a linear actuator, then another vibrator, just because it got added that way in the device config. This makes building client APIs awkward.
Sensor Ambiguity
For SensorCmd, there's 2 possible commands: Read, and the Subscribe/Unsubscribe pair. There is a chance we could have a sensor that is capable of being both read AND subscribed, which, if defined incorrectly, could have different indexes reported for what is the same sensor. Similarly, even if we do try to line those up, since we're using indexing implicitly via array indexes, the user can't tell when things stop being the same sensor.
For instance, let's say we have a device with 1 sensor that is readable AND subscribable, then one that is readable, and one that is subscribable. We've had the read/sub device as index 0 in both the SensorReadCmd and SensorSubscribeCmd portions of the device info. However, the sensor at index 1 of SensorReadCmd would be different than the sensor at index 1 of SensorSubscribeCmd.
Mitigation for now
This can't really be fixed until there's another spec change, which I'd like to avoid going until v3 has at least had a bit more time to bake. Until then, we can make a best effort in APIs to reflect this issue. I don't see it causing major problems yet since we don't even really have devices with sensors period, but as long as we provide client APIs that don't reveal this issue to the user directly, we can hopefully fix it under the covers in the future.