Any brave dive computer download testers out there?

Linus Torvalds torvalds at linux-foundation.org
Mon Apr 23 10:07:36 PDT 2018


On Mon, Apr 23, 2018 at 12:56 AM, Sébastien Dugué
<sebastien.dugue.subsurface at gmail.com> wrote:
> On Sun, Apr 22, 2018 at 10:09 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>>
>> It still has the exact same problem it always had: it's random binary data
>> that we'd have to encode some way.
>
>   Well, it's not so random. It's in fact a timestamp in the DC format which
> specifies from which dive we wish to download.

I wish that was the case. It's not.

It's a timestamp on _some_ dive computers. On others, it's other random data.

On most dive computers, it's 4 bytes, on others it's 5-6, and on some
it's 16 bytes of random binary data.

On many dive computers it's entirely pointless (yes, yes, you may be
able to avoid downloading that one last dive), but they still have a
fingerprint, and there's no way to know "don't bother".

So to really get it right and download the least amount of dives you have to:

 - encode this insane random binary data without knowing what it is

 - also encode the insane garbage "serial number" (that isn't actually
a valid serial number at all, and hasn't even been stable across
libdivecomputer versions)

 - then before downloading, match the garbage serial number and
vendor/device string to find the last dive with that dive computer, in
order to find the other garbage random binary data

honestly, it's nasty nasty nasty.

What we *could* do is to do it knowingly wrong, the way dctool does
it: don't save the fingerprint data with the real dive data at all,
just have a random "last download" cache indexed by device family and
serial number.

That's how the feature is designed to be used, and it would avoid the
nasty "pollute our logs with meaningless and badly defined crazy data
that will never be useful in the future".

"So why don't you do that, then?" I hear you say.

It's probably the best approach, and works fine if you just always
download from the same device (because the cache would be specific to
the installation, not be part of our dive data). And when it doesn't
work, arguably we wouldn't be in any worse condition that we already
are in (ie "download everything" from the devices that can't download
dives one by one), so why not?

The "why not" is because it makes re-downloading dives much nastier.
If you actually want to re-download dives (maybe because you didn't
save the dives after the last download due to some other problem?) you
now need a way to clear the cache data. And the "download all dives"
thing could do that, but then  you wouldn't have the existing "don't
duplicate dives" that we *currently* have.

But it also means that when you download from the same dive computer
on a different device (ie your phone vs your laptop), you'll get get
potentiall ydifferent results. It can be very confusing.

So it's a hack, but it might be acceptable. As long as I don't have to
save that stupid fingerprint - and that broken serial number that
isn't - in the logs, I'm certainly happier with it.

                Linus


More information about the subsurface mailing list