handling fingerprints

JB2Cool jb2cool at gmail.com
Sat Nov 13 14:52:34 PST 2021


I think i understand what i'm meant to be testing but i can't seem to get
any functional difference between using 5.0.4 and 5.0.4-27-gb87cbed53cd6.

Can you spell it out for dummies how to test this for you (I know you've
already written it out but i'm talking farm animal stupid instructions). I
think what's confusing me is your mention of deleting a dive from the
logbook, do you really want the dive computer to have more current info
than the saved dive log? I'm doing this as an entirely separate computer
user using a different cloud storage account so there is no fear/issue with
messing up anything in my everyday log, I'm using Windows desktop
application and Linux AppImage and an OSTC Plus if it makes any difference.

Sorry to be a pest
Jason

On Sat, 13 Nov 2021 at 00:19, Dirk Hohndel via subsurface <
subsurface at subsurface-divelog.org> wrote:

> To avoid confusion:
>
> you'll need Subsurface-mobile 3.4.1(or newer) and Subsurface 5.0.4.25 (or
> newer) to test this...
>
> /D
>
> > On Nov 12, 2021, at 3:46 PM, Dirk Hohndel via subsurface <
> subsurface at subsurface-divelog.org> wrote:
> >
> > My code to share fingerprints via the cloud has been merged into master.
> > Android test binaries with that new code are pending review to be pushed
> into the beta channel.
> > I'll work on iOS test binaries in a moment.
> >
> > It would be extremely helpful if this could get some testing.
> > This new feature is extremely useful for Scubapro G2 users (download via
> cable on your PC and when you next attempt to download via BLE on your
> phone the right thing happens).
> > The G2 is certainly the most egregious case - but I'm sure this will
> help with some others that I'm not aware of where having the correct
> fingerprint also makes a difference in download duration on mobile.
> >
> > In order to test this you need a dive computer that you can download
> from on two devices - doesn't matter if its mobile or desktop.
> > Test scenario: force a download on one computer/device (either delete
> the last dive or force download all dives). Sync with cloud, sync with
> cloud on the other computer/device.
> > a fresh download should successfully use the fingerprint and immediately
> tell you that there are no new dives.
> >
> > /D
> >
> >> On Oct 23, 2021, at 5:12 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >>
> >>
> >> 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 at subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20211113/826f1116/attachment.htm>


More information about the subsurface mailing list