On Wed, Oct 22, 2014 at 10:52:42AM +0200, Jef Driesen wrote:
Storing the firmware per-dive is actually the right thing! If the firmware versions is needed for parsing (e.g. firmware dependent data format), then the current firmware version is useless, because you need to know the version at the time the dive was recorded. This is not only true for the firmware versions, but also other things like settings.
We already have other backends where we figure out the firmware version while parsing a dive (OSTC comes to mind, but I think there are others). There it's much more that we switch between two known layouts, but that's fundamentally the same thing.
You certainly should not emit the devinfo event more than once. Let me explain why.
The primary purpose of the devinfo event is not an interface to pass the firmware version to the application. It has been designed for use with the fingerprint feature. When the application gets the devinfo event, it should lookup whether it has a fingerprint for that specific device, and register it with the dc_device_set_fingerprint function. To be able to distinguish different devices, I needed something that's unique for each device. And that's where the serial number comes into play, because serial numbers are supposed to be unique. However for this purpose, the serial number as used by libdivecomputer doesn't have to match exactly with the real serial number. That's why decoding it as a number is fine for this purpose. In theory we could even calculate a hash here.
Which reminds me. I STILL need to redesign our libdivecomputer code to correctly use fingerprints. So many things to do, so little time.
I agree with you, that for communicating the real serial number and firmware version to the application we'll need some different interface. And yes, strings will be more appropriate here. No need to convince me about that. But right now, we can't change that without breaking backwards compatibility.
In the past you have been criticizing more than once, that I shouldn't break backwards compatibility. I got the message, and I no longer do this. But now you're complaining that we're stuck with a bad interface because of that? What do you expect me to do?
Anyway, my advice is that for now you encode the serial and firmware version as a number for the fingerprint feature, and at the same try to keep it at close as possible to the real fingerprint. Once we fix this design mistake after v0.5, we can return the real values.
Here I'm confused. So we are already adding a few new things to 0.5 compared to 0.4. What is stopping us from adding two new optional APIs?
DC_EVENT_SERIAL which returns a string with the serial number DC_FIELD_VERSION which returns a string with the firmware version for this dive
If the backend doesn't support them the app will need to fall back to the existing means of discovering these data - but for backends which support this, we can indeed return appropriate strings...
Am I missing something?
/D