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

[Dirk Hohndel]

On Jan 12, 2013, at 1:15 PM, Jef Driesen wrote:

> 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 :-)

But that will be all better with the fully documented next API :-)

> 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.

Well this works, but I really would LIKE a string. I'll tell you why. Remember the Atomics documentation where they tell us "it's these four digits, then a dash, then those four digits". I bet there are other vendors that have letters in there, too. So having libdivecomputer give us a \0 terminated string would really be lovely.

Can I ask everyone on both of these mailing lists to take a look at their actual divecomputers and tell us what format your serial numbers have, please?

/D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4130 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20130112/3df7c82d/attachment.bin>