Checkpoints

[diocas]

Implement the checkpoints handlers for Jupyter. In Jupyter, these handler are independent of the save mechanism. Only if the user clicks in the save button (as opposed to automatic saves) - and the save is successful - the endpoint to create a version is called.

[diocas]

We need to decide the best way of implementing this when using the CS3APIs. On EOS, for example, the versions are created automatically.
And my assumption is that there is still no mechanism to decouple file versioning from the saving of a file. @labkode can you confirm this? Do you have any suggestion?

Currently, at CERN, we rely that a version was created during the save. So, in practice, the Jupyter endpoint to "create" a version only checks if a new version exists or not. The disadvantage is that we keep creating versions when the autosave kicks in, as opposed to only do that when the user clicks save.

[JarCz]

Now, I see three ways of implementation checkpoint in cs3api4lab:

• save checkpoint files in hidden container at IOP instance:
  ◦ riva generate files version on save operation, we have duplicate functionality
  ◦ problem with duplicate network request
  ◦ to save file is used twice operation. First to normal save, second to save checkpoint
• save checkpoint files at local user system in home folder like as normal JupyterLab functionality:
  ◦ if user work on multiple computers we have problem of file version, user see only files version on current computer
• use a version of files from IOP instance, example from Riva folder /var/tmp/reva/.shadow/versions/{USER_NAME}/{FILE_NAME}:
  ◦ probability we need to create new api at Riva
  ◦ do all storage provides supports this functionality?

@diocas @labkode

• What is in your opinion the way to implement the checkpoint?
• Do we see another way or problems on those ways?

[diocas]

Sorry for the late reply, I didn't see this ticket.
I'll discuss this further with @labkode once he returns from holidays.
Either way, as we discussed in the last meeting, the versions integration is not the top priority atm. To add to this, I also have a ticket open with upstream because they don't have the expected behavior on this functionality and I'm expecting a fix.

But about your suggestions, I think the jupyterlab versioning should be exactly the same as any other application. If I create a version in Jupyter, then I want to see it from CERNBox/ownCloud and, maybe in the future, in the sync client. So I don't agree we save versions manually in different places, thus bypassing the normal logic.
It is true that saving already creates a version. At some point I had a discussion with @labkode and I proposed we can pass a flag to disable versioning on save. This way, we can call versioning after as a manual step (which also needs to be added in the CS3APIs).

If this is not possible, I would implement the same behavior we currently have in SWAN: creating a version does not create a version. It assumes that the save already created one, so it just returns the latest.

[diocas]

@mateusz-garlacz I've had a preliminary discussed with @labkode and it might be interesting to enable checkpoint functionality similar to what Jupyter does. But we still need to discuss it further (and eventually have it implemented).
But, as I mentioned above, this is not a priority for now.

[diocas]

Still needs implementation: cs3org/cs3apis#97