Device serial numbers [was: Clean up some of the dive computer nickname code]

[Dirk Hohndel]

Jef Driesen <jefdriesen at telenet.be> writes:
>> It could be as simple as a new libdivecomputer callback ("given this
>> serial *number*, what is the string for it?"), but it would probably
>> be better to expand the current DC_EVENT_DEVINFO event to simply give
>> us a string in addition to the number. Because it's not necessarily
>> the case that all serial number strings can even be represented as a
>> single 32-bit integer.
>
> The primary purpose of the serial number in the DC_EVENT_DEVINFO event 
> is to be able to uniquely identify individual devices (e.g. for use with 
> the fingerprint feature). For this purpose, it doesn't really matter if 
> the serial number (as returned by libdivecomputer) doesn't match the 
> real serial number (as printed on the hardware). That's why I didn't 
> bother to decode it properly, and just return the raw bytes wrapped in a 
> 32bit integer. In this sense the serial number is more like an opaque 
> device id, and it was not really intended to be shown to the end-user 
> (e.g. for warranty purposes).
>
> Until now, all serial numbers did nicely fit into a 32bit integer, but 
> if there ever happens to be a device where this isn't possible, we can 
> always calculate some hash, just like you already do in subsurface. But 
> of course that will only work if we make no guarantees that the 
> libdivecomputer serial number will match the real serial number.

You are solving the wrong problem. As was discussed earlier on the list,
being anle to show the "user readable" serial number in the dive log is
a feature - one that we are interested in having.

That's why Linus suggested a new callback that returns the serial number
STRING for those devices where it is known how to create it. So no
change is suggested to the existing 32bit number - just the addition of
a human readable serial number to the API.

/D