First cut at EON Steel patches

[Dirk Hohndel]

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