Endpoint discovery through https://example.com/ocm-provider/

[michielbdejong]

In practice, if servers A and B participate in the OpenCloudMesh, and Alice@A wants to share a resource with Bob@B, then the first thing server A will do is to do a GET to https://B/ocm-provider/, for end-point discovery.

I don't think this practice is currently documented in this spec repo, but without it, OCM doesn't work.

There is another option - we could define endpoint discovery to be out-of-scope, meaning OpenCloudMesh will only work between previously federated servers. This is for sure how it will be used in ScienceMesh, so there it's fine, but in general, I think it would be a pity to lose the open-ended host discovery.

[michielbdejong]

Unlike Nextcloud and ownCloud, reva uses a providers file (whitelist including config for each provider).

[glpatcern]

Following the CS3 event in Barcelona, there are two points that came up on this, prior to merging #59:

1. Do we agree to expose on the resourceTypes.protocols list the top-level URL endpoints for each protocol? Which implies that the share action would provide URLs relative to those endpoints? The advantage for this scheme - according to Nextcloud - is to allow for an EFSS instance to move e.g. to a different domain without loosing all established shares. Of course, this would also imply that the discovery endpoint MUST be called by the EFSSs every now and then to refresh such top-level URLs. Note that if we go this direction, also ScienceMesh would depend on the discovery endpoint - which I think it's fine.

2. We should make it clear that implementations may provide any resourceType, shareType, and protocol as optional capabilities, whilst stating that the minimum requirement for an OCM-compliant implementation is to have a given minimum set of capabilities. IMHO a reasonable minimum would be resourceType = file, shareType = user, protocol = webdav. So far this is not mentioned anywhere, as apparently there were reasons to not "impose" webdav as minimum common protocol. Time to change?

[smesterheide]

1. Do we agree to expose on the resourceTypes.protocols list the top-level URL endpoints for each protocol? Which implies that the share action would provide URLs relative to those endpoints? The advantage for this scheme - according to Nextcloud - is to allow for an EFSS instance to move e.g. to a different domain without loosing all established shares. Of course, this would also imply that the discovery endpoint MUST be called by the EFSSs every now and then to refresh such top-level URLs. Note that if we go this direction, also ScienceMesh would depend on the discovery endpoint - which I think it's fine.

Interesting point you make regarding change of domains. I would consider this out of scope for the specification, but it is definitely worth exploring. My gut feeling is it has more implications than loss of established shares.

[glpatcern]

Interesting point you make regarding change of domains. I would consider this out of scope for the specification, but it is definitely worth exploring. My gut feeling is it has more implications than loss of established shares.

I can imagine. That was what came up discussing with Bjorn, but indeed the implications and the added complexity do not seem to be worth the effort.

Could you please paste here the payload of a new OCM share in Nextcloud? in particular, do you pass the URL as relative to /public.php/webdav/, that is what Nextcloud currently returns on its /ocm-provider endpoint?