> On 22 Mar 2016, at 22:16, Dirk Hohndel <[email protected]> wrote: > > >> On Mar 21, 2016, at 5:17 PM, Miika Turkia <[email protected]> wrote: >> >> I am currently suffering from poor network connectivity and cannot sync the >> desktop app to the cloud. Looks like it times out before ssl hand shake is >> finished. I tested the connectivity with openssl and it took about 60 >> seconds for the connection to initialize properly to cloud port 443. (TCP >> connects within a second or two.) Can the timeout be easily extended >> somehow? As we all know many divers do frequent this kind of poorly >> networked locations. >> >> I can grab verbose logs or network capture at some point if my initial >> assumption of the root cause proofs to be wrong. > > If openssl takes 60 seconds, then Subsurface won't be any faster - and we > time out way before that. > > I have thought about this problem (and I'm pretty sure we discussed it here) > before. The problem is that once we successfully connect with the server we > reset the dive list - which means that changes that the user has made since > we initiated the cloud connection might get lost. If we allow massively > delayed sync (a minute or more), then this is likely to cause users some > frustration. > > We could freeze the UI or make things read only while the sync is running, > but I'd perceive that as a really poor user experience, especially if I'm at > a place where the sync won't complete, ever. > > I'm open to ideas - but simply making the time out longer would seem to be > asking for trouble.
A dialog asking whether to attempt slow sync mode or work off-line comes to mind. I just managed to run the sync and even now the ui was totally frozen for several minutes during the sync. Of course a different case as git was working... miika _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
