request for comments: suggest flow for saving to cloud storage

[Dirk Hohndel]

On Thu, Oct 19, 2017 at 09:43:12AM +0200, Willem Ferguson wrote:
> On 19/10/2017 04:06, Dirk Hohndel wrote:
> > 
> > Plam A: "save to cloud" is grayed out unless you first "open cloud
> > storage".  And it gets grayed out again once you close the dive file.
> > 
> > Plan B: if the current dive file wasn't "opened from cloud storage",
> > change the text of the menu option from "Save to cloud storage" to
> > "Overwrite cloud storage" and add a confirmation dialog in that case.
> 
> Do not save an empty dive log to cloud

That would indeed be a quick and partial fix.

> This is probably something that will not be solved in 4.7 because there is a
> fundamental issue at stake. If you think that the desktop has problems with
> cloud storage, just look at the mobile app that only has one option
> "synchronise with cloud". The question is how to deal with a divelog
> accessed from more than one device that may have different versions of the
> dive log. A user edits some dive details on mobile, loads some dives from a
> dive computer using the desktop and all this information needs to be
> maintained in a sane way. Part of the solution is to make a distinction
> between "Save to cloud" (overwite is not the correct term because within git
> language one can by definition not overwrite) and "Sync with cloud" and to
> make both options available on mobile as well as desktop. When either Save
> or Sync is selected, there is a need for a short summary of changes ("6
> dives will be added; 0 will be deleted; 2 will be changed") with an option
> to abort the save/sync process at that stage.

The odd thing is that almost always git will get it right. We've now seen
two cases where git made a mess of the edit here, edit there, just sync
and assume it works. That's two out of more thabn a hundred thousand of
git sync operations against the Subsurface cloud storage. That's a pretty
decent rate.

Yes, I like the idea of showing stats. Getting those "right" will be hard,
though. And no, I don't want to offer "overwrite" on the mobile app. I
can't see a scenario where that's what you want.

> Ultimately there is a need for a recovery mechanism that Dirk has mentioned
> already, providing a list of versions of the dive log from git (maybe with
> dates) and allowing to restore a particular version of the divelog.

As usual, the main issue here is the UI.

> When using a sophisticated and flexible database such as a dive log and a
> user demands many features, then a sensible and informed way of working with
> that database is also to be expected. If one wants a simple way of working
> with the database, then do not make use of the more flexible facilities. My
> point is that the whole onus should not only be on the programmer's side,
> but the user also has some responsibility with respect to the integrity of
> the dive log, not to do stupid things. But, for V4.8 it would be nice if
> there is a recovery mechanism in case shit does happen.

Agreed.

/D