Fwd: Re: request for comments: suggest flow for saving to cloud storage

[Willem Ferguson]

On 19/10/2017 04:06, Dirk Hohndel wrote:
> Hi
>
>
>
> 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.
>
>
>
> /D
>

Do not save an empty dive log to cloud

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.

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.

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.

Kind regards,

willem



-- 
This message and attachments are subject to a disclaimer.
Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full 
details.