Open michielbdejong opened 3 years ago
When designing the CS3APIS we split the OCM sharing (called federated share) from internal sharing (cs3/sharing/collaboration).
Does it make sense?
the cs3 uses three separate sharing APIs:
At least that was the intention. It does create some friction an boilerplate, but I think keeping them separate does make sense.
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.
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.
While investigating https://github.com/cs3org/reva/issues/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 andsharing/collaboration
is used by the receiver of a share, but if that's really the explanation then we should probably rename them to something likeocm/sender
andocm/receiver
, respectively?