Add forking API

[davidbrochart]

The forking API consists of the following endpoints:

• PUT /api/collaboration/fork/{root_roomid}: creates a fork of a root document (optionally synchronizing with the root document).
• DELETE /api/collaboration/fork/{fork_roomid}: deletes a fork of a root document (optionally merging back in the root document).
• GET /api/collaboration/fork/{root_roomid}: returns the fork IDs of a root document given by its ID.

Jupyter events are emitted when creating and deleting forks.

[github-actions[bot]]

:point_left: Launch a Binder on branch _davidbrochart/jupytercollaboration/suggestion-api

[trungleduc]

Downstream users need to interact with the REST API and the Event handlers directly or will you introduce the JS APIs later?

[davidbrochart]

Downstream users need to interact with the REST API and the Event handlers directly or will you introduce the JS APIs later?

Yes we can add higher-level JavaScript functions, maybe in another PR?

On a different note, I'm not sure if a fork's room ID should just be uuid, or format:type:uuid. Currently it's the former, because if it were the latter it would be interpreted as a stored document, but we don't want forks to be stored, do we?

[trungleduc]

Yes we can add higher-level JavaScript functions, maybe in another PR?

Yes, let's merge this one then I can work on this

[davidbrochart]

On a different note, I'm not sure if a fork's room ID should just be uuid, or format:type:uuid. Currently it's the former, because if it were the latter it would be interpreted as a stored document, but we don't want forks to be stored, do we?

We need to answer this question before merging.

[trungleduc]

if it's only about changing the ID format, Isn't it safer to store the forks and we can remove them later if we don't have to?

[davidbrochart]

But a stored document currently means that it goes through the Jupyter file ID service and that it is a file-backed document. So that would mean adding logic to manage (temporary) files for these forks.

[trungleduc]

ah, I thought that the fork data is saved into the .jupyter_ystore.db file

[davidbrochart]

If it's a stored document yes, but it's not at the moment.

[trungleduc]

creating a file-less document where all data is stored in the .jupyter_ystore.db file could also be useful for the chat application?

[davidbrochart]

Yes. But does it make sense to store suggestions?

[trungleduc]

Yes. But does it make sense to store suggestions?

Google Docs keeps the suggestions till we explicitly delete them so I say yes.

[davidbrochart]

I'm thinking that we should maybe create a new branch to work on forking/suggestions, instead of taking the risk to block main or release completely WIP code.

[davidbrochart]

But then it won't help you if you want to use the new features in JupyterCAD?

[trungleduc]

But then it won't help you if you want to use the new features in JupyterCAD?

there is no problem, I can link my work with your PR

[jtpio]

Wouldn't the forks need be saved also in the case of server restarts? Users would probably expect their suggestions to be there if they resume their work later?

But then it won't help you if you want to use the new features in JupyterCAD?

Maybe there could be some pre-releases made from the new branch? Or one could download the artifacts built by the releaser to use the latest version.

[trungleduc]

@davidbrochart could you rebase this PR to bump its version to 3.0.0? I trying to install it locally.

[davidbrochart]

Superseded by #394.