Any brave dive computer download testers out there?

[Dirk Hohndel]

> On Apr 27, 2018, at 7:29 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
> 
> The fingerprint usually contains the raw date/time data, but it depends on the dive computer. Why should the application need to know what's inside? It only needs to store the data somewhere until the next download.

This is our usual argument, Jef. You like black boxes and abstractions. We (as the app using libdivecomputer) would prefer having more control and fewer abstractions, as often the abstractions that you chose don't work for us as well as one might hope.

Additionally, I don't think that the issues around using libdivecomputer across multiple devices that share dive information is something that is fully appreciated in your design. And of course our desire not to store unnecessary, basically redundant data.

> Using something less arbitrary for the fingerprint data, like a hash over the dive data or even the date/time of the dive, doesn't work. There are several reasons for that:
> 
> 1. As explained before, the Uwatec/Scubapro protocol requires sending the timestamp to the dive computer. That already rules out the use of a hash, because we can't retrieve the timestamp back from the hash. Even using the date/time is tricky here, because this timestamp should be relative to the device clock, not the host clock. Since some of those devices rely on the host clock for parsing the date/time, that means you would have to store those values as well. Using the raw dive timestamp as the fingerprint doesn't have those problems.
> 
> 2. Many dive computer protocols support downloading some kind of index with a summary of the available dives. That allows libdivecomputer to check the fingerprint and decide which dives need to be downloaded before actually downloading the dive. That's not only a bit more efficient, but it also allows to deliver much more accurate progress events. That improves the user experience. So this is not only about being a little bit faster. But this is only possible if libdivecomputer can use whatever information is available in the index that can uniquely identify a single dive, and that's of course different for each protocol. Hence the need to use arbitrary data.
> 
> So even if you don't really care about this last argument, then how would you handle the first one?

I don't think there's a lot of point re-hashing these arguments. I actually see how this approach that you have taken is valid to solve the problem you were trying to solve.
And I'm not 100% convinced that our current approach is the right one - this is something where I need to find time to think about the design and come up with maybe a better alternative (and then I get to argue with Linus :-) )

> The only alternative solution that I can think of is to replace the fingerprint with the raw dive data itself. That way, the feature would still work exactly the same as before, but with the entire dive as the fingerprint. Internally libdivecomputer can still extract and use whatever piece of info it needs for its implementation. The disadvantage is that you now need to store the entire dive (which is a lot larger than just the fingerprint), but at least it's some more meaningful data.

That seems quite silly - it only makes the "random binary data" argument worse.

/D