-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Caps Disco #136
base: caps-disco-base
Are you sure you want to change the base?
Caps Disco #136
Conversation
The current |
Concerning apiVersion, IMHO its useful for humans, as the branding, and should NOT be relied upon to decide on caps. Yet it is used for that by Nextcloud. |
Capabilities should be about being able to process something you receive. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I think we can include the full list in the spec as per #121 !
@@ -236,10 +236,10 @@ Step 7: The JSON response body is the data that was discovered. | |||
The JSON response body offered by the Discoverable Server SHOULD contain the following information about its OCM API: | |||
|
|||
* REQUIRED: enabled (boolean) - Whether the OCM service is enabled at this endpoint | |||
* REQUIRED: apiVersion (string) - The OCM API version this endpoint supports. Example: `"1.1.0"` | |||
* REQUIRED: apiVersion (string) - The OCM API version this endpoint supports. MUST start with `"1."` and clients MUST ignore the rest of the string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd not impose restrictions here on the content. Maybe just It is provided for information purposes only: clients SHOULD NOT infer capabilities based on its value
.
@michielbdejong can you please rebase this on top of |
In my presentation about OCM at CS3 2023 in Barcelona I had this slide about CAPabilitieS DISCOvery ;)
Now I'm thinking if we put good capability discovery into the
/.well-known/ocm
//ocm-provider
document, then discovery doesn't even have to rely on theapiVersion
field we have there. Older implementations will just have less entries in the capabilities object, or the object will be missing from the document altogether.