Partial push of Josh's configure-dive-computer GSoC project

[Dirk Hohndel]

On Thu, Aug 14, 2014 at 06:08:00PM +0200, Jef Driesen wrote:
> What do you mean with "all cases"? For the OSTC it will always remain the
> same, unless HW suddenly changes their dataformat (for example 3 bytes
> instead of 2). If you mean for all backends, then no, each backend may use
> it own encoding.
> 
> I assume you get firmware version from the devinfo event? Unless you extract
> the firmware version from the raw data yourself, that's the only place where
> libdivecomputer exposes the firmware. But initially this firmware number was
> intended for internal use only. It was added in case one of the parser would
> need the firmware version (e.g. change of data format after a firmware
> upgrade). But so far that was never needed, because either the format never
> changes, or if it did like in the case of the ostc, the format version was
> embedded in the dive data. For this purpose, the actual encoding doesn't
> matter because obviously libdivecomputer knows how it encoded it.
> 
> But now we're of course stuck with this one integer firmware version that's
> not necessary human readable (same applies to the serial number).

As always, my take on this is "it is what it is, for compatibility we'll
not ask you to change things". And you use this type of byte boundary
encoding  in several places, so this isn't that problematic, anyway.
All we need to do on our end is to wrap this in appropriate accessor
functions.

Linus is working on the new gas change logic and as part of this we'll
embed a real gasmix in our event structure - but we'll keep things as they
are in the file format whenever we have no additional information - simply
to ensure maximum forward and backward compatibility. It's just solid
engineering to do so.

So in summary - the format for version encoding doesn't bother me at all.

/D