"protocol" or "protocols", which should implementers use? about ocm-api

[smesterheide]

Yes, I think so. This is what I demonstrated at CS3 Barcelona, and Bjorn even came up with another example where this model fits nicely.

My apologies, I was not following the discussion around the protocol issues co closely. In that case the protocols spec makes sense with protocol names (webdav, webapp, datatx) as properties.

As a first step let's link to both versions, instead of only to the "develop" version, from our readme ^

Agreed

[glpatcern]

Completely agree! As a matter of fact, we could preserve protocol and even pretend that we are backwards compatible, because the current specs just leave the protocol payload completely undefined. And as discussed with the Nextcloud crowd (@schiessle and @smesterheide), the reality check showed different vendors being incompatible between each other, hence the need for more details.

IMHO we should still spell out the attributes each protocol / access method requires, whilst making it clear that the minimum requirement for an OCM-compliant implementation is not to have everything: a reasonable and required minimum would be resource type = file, shareType = user, protocol = webdav. And all the rest is optional (though somehow in the specs).

[smesterheide]

Do we need more than one protocol at a time? I think the original definition was superior to having different protocols defined as properties. Can we use name as a discriminator?

[glpatcern]

Do we need more than one protocol at a time?

Yes, I think so. This is what I demonstrated at CS3 Barcelona, and Bjorn even came up with another example where this model fits nicely. Imagine you share a calendar event, and you want the recipient to access the event data via CalDAV (i.e. protocol = webdav), as well as connecting to some groupware tool such as Zoom, Nextcloud talk, etc. (i.e. protocol = webapp).

I think the original definition was superior to having different protocols defined as properties.

The original definition was just an object, which does not offer any clue as of how implementations are supposed to encode the properties. No surprise that compatibility across different vendors was not ideal (e.g. only recently did Seafile announce compatibility with Nextcloud).

[michielbdejong]

does not offer any clue

That's a separate issue, unrelated here I think.

only recently did Seafile

Also not relevant to this discussion, I think.

My own (simplistic) answer to this question would currently be:
If you want to do OCM over the internet, use "protocol"
If you want to do OCM over ScienceMesh Network Alpha, also use "protocol"
If you want to do OCM over ScienceMesh Network Beta, use "protocols"

If that is the current situation then the is what our docs should say.

So the information people need is currently (even if this is temporary) a combination of https://cs3org.github.io/OCM-API/docs.html?branch=v1.0.0&repo=OCM-API&user=cs3org and https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org

We are currently only pointing them to https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org so we are misinforming them.

[michielbdejong]

As a first step let's link to both versions, instead of only to the "develop" version, from our readme ^