On Dec 23, 2013, at 4:29 PM, Linus Torvalds <torva...@linux-foundation.org>
wrote:
> On Mon, Dec 23, 2013 at 1:25 PM, Dirk Hohndel <d...@hohndel.org> wrote:
>>
>> Linus - I don't remember why we did not use the fingerprint based
>> implementation... can you remind me?
>
> The fingerprint was too much random crud to actually bother saving
> without a sane format (it's just a byte blob). We do use it (to
> generate the dive ID), but we have turned it into something much more
> easily used for our needs.
>
> Also, it's useless for all the cases we had actually seen, so there
> was very little reason to even worry about it.
>
> But I guess we could save it off for specific dive computers, and then
> in libdivecomputer.c:event_cb(), we cowhen we've calculated the
> deviceid, we could do something like
>
> /* We don't have this right now, it would walk dives
> * starting from the most recent to the oldest */
> for_each_dive_reverse(dive, i) {
> for_each_dc(dive, dc) {
> if (dc->deviceid == devdata->deviceid && dc->fingerprint) {
> dc_device_set_fingerprint(device, dc->fingerprint);
> return 0;
> }
> }
> }
>
> or similar (the above is pseudo-code and the fingerprint isn't a
> string, it would have to be a blob with length etc).
Yeah, I was thinking of simply converting the fingerprint into hex
digits and storing those and then put wrappers around that to
transparently convert from one to the other.
> But this seems to be the first device to actually need it, and the
> 1.5h download seems to really be due to some independent problem (ie
> something is much too slow regardless).
I seem to remember that we had a couple of other reports of devices that
DOWNLOAD all the dives (before showing them to us) unless you tell them
which dive is the last one that you have. I’m sure Jef will have the data on
that :-)
_______________________________________________
subsurface mailing list
subsurface@hohndel.org
http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
