How do `ocm/core` and `sharing/collaboration` relate?

[michielbdejong]

While investigating cs3org/reva#2148 I ran into a question:

Why is there on the one hand a cs3/ocm/core package, with:

• CreateOCMShareRequest

And on the other hand a cs3/sharing/collaboration package, with:

• CreateShareRequest

I think that ocm/core is used by the sender and sharing/collaboration is used by the receiver of a share, but if that's really the explanation then we should probably rename them to something like ocm/sender and ocm/receiver, respectively?

[labkode]

When designing the CS3APIS we split the OCM sharing (called federated share) from internal sharing (cs3/sharing/collaboration).

Does it make sense?

[butonic]

the cs3 uses three separate sharing APIs:

• the LinkAPI is used for public links
• the CollaborationAPI is used for shares to users or groups on the same instance
• the OcmAPI is used for federated shares

At least that was the intention. It does create some friction an boilerplate, but I think keeping them separate does make sense.

[ishank011]

Elaborating on @labkode's comment, cs3/ocm/core exposes unprotected endpoints to which other providers can make requests to. For example, for a share created on Surfsara, the metadata would have to be persisted at CERNBox as well. This is the CreateOCMCoreShare call

The cs3/sharing/ocm API exposes endpoints which users belonging to a given provider will call to create an OCM share. This is the CreateOCMShare call. This in turn calls CreateOCMCoreShare on the recipient share provider.

The cs3/sharing/collaboration API does not concern OCM and enables shares among local users.

[michielbdejong]

Ah ok, thanks! Is there a documentation page about this somewhere? If not, let's create one.

So then maybe we can rename CreateOCMShare to something like CreateOCM[Outgoing/Sent]Share and
rename CreateOCMCoreShare to something like CreateOCM[Incoming/Received]Share?

The word 'Core' isn't very clear, I think.