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

[Jef Driesen]

On 10-01-13 16:57, Dirk Hohndel wrote:
> 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.

Oh, but I was mainly responding to the Linus' statement that the libdivecomputer 
serial number is wrong. But it's not really wrong if you take into account how 
it was supposed to be used. Yeah, I know, some documentation would have been 
nice here :-)

Anyway, we can just fix the decoding of the serial number of course. For the 
fingerprint feature it doesn't have to be decoded correctly, but that does mean 
we can't decode it correctly either (see attached patch). I would prefer that 
instead of adding another callback with a string. A plain number is more 
convenient than a string (I hate string processing), especially for things that 
are numbers. How the number is stored by the device is irrelevant. If we ever 
encounter a serial number that isn't a number or is larger than 32 bits, than we 
can always reconsider.

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip_suunto_serial.patch
Type: text/x-patch
Size: 2485 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20130112/b30374b3/attachment.bin>