On 10-01-13 16:57, Dirk Hohndel wrote:
Jef Driesen jefdriesen@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