Hey Linus,
The more I think about our current fingerprint handling (I think that's our third attempt), the more I think we are still not doing this right. Right now we consider fingerprint files specific to a host (so the specific system - PC, laptop, phone, tablet) that Subsurface runs on. So let's say I have a PC and a phone. I use the cloud to store my dive data. And I also want to download my dives for a research project into an XML file. (1) on my PC I download from my dive computer and store the dives in the cloud -> there is a fingerprint file in the PC file system and the dives are in the cloud (2) after a couple more dives, I download again -> Subsurface finds the fingerprint file and only downloads the new dives; all good, fingerprint file on the PC and cloud dives get updated (3) close the cloud storage, open a local .xml file; download again -> fingerprint file is found, but the matching dive is not in the dive list, so fingerprint gets ignored (but why are we even looking at it???) -> dives are downloaded, fingerprint is written again (4) more diving, this time I only brought the phone -> no fingerprint file on the phone, all dives are downloaded -> new dives go in the cloud, fingerprint file on the phone (5) no additional diving, back on the PC -> those last dives would attempt to download again (the fingerprint is outdated), but after the first one downloads we'd recognize that we already have it and give up -- without updating the fingerprint file on the PC (6) I buy a new phone, connect to the cloud, then try downloading from the dive computer -> even though all the dives are in the cloud, because there is no fingerprint file, we download from the dive computer -> because no new dives were downloaded, no fingerprint file is written - so we do this every time until the next time we actually have a new dive that's downloaded on that phone (3), (4), (5), and (6) all indicate that what we are doing isn't really right The fingerprint information really is tightly related to the dive log file. That's why we have this check in (3) to prevent us from ignoring the dives on the dive computer if the fingerprinted on isn't in the dive list. I can actually turn (4) and especially (6) into a really annoying situation with a dive computers like the G2 where we keep downloading all dive data if we don't have a fingerprint (there is no "give me the newest dive" function - if you don't have a fingerprint you download everything) -- and of course all this is especially frustrating when this is a BLE download that takes for ever and is super flaky. I am back to thinking that we should consider the fingerprint a property of a specific dive log. So both an XML file and the git storage should remember the last fingerprint for each dive computer from which we did a direct download. And we should index that exactly like we name these files in the filesystem right now - model.devinfo-serial - and then have the fingerprint data be a hex encoded byte stream of fingerprint-deviceid-diveid. Sadly, this still causes pointless re-download orgies when a firmware change or some other change messes with the devinfo-serial number which we have to use as lookup parameter - but it seems like it would get more cases right than what we have today. Of course, this all is triggered by the plight of specifically G2 users. And the annoying fact that even if they do the full download on a PC via cable, they still have to get a full download to work on their phone via BLE... I'd much rather come up with a way to not rely on the devinfo-serial number, but at least on the G2 that one looks like it should be stable (there's no way to get the firmware version on the G2, it seems). I wonder if I am missing something in my model here... is there a scenario where storing the fingerprint with the dive log file creates incorrect behavior? At least for the important case (dive computer that supports both wired and BLE transfer - do the fast wired transfer on the PC and have the correct fingerprint for the next BLE transfer both locally AND and on the phone) this seems like it would be an improvement... Thoughts? /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
