Type of change
Since most of the extensions should be optional it’s important to for clients to have a way to know what the server actually support.
Server should expose that it support extensions and implement an endpoint that list the supported endpoints.
Backward compatibility impact
Exposing a new field should not have impacts nor adding a new endpoint.
Add a new field
supportExtensions : Boolean - True if support at least one extension
- New endpoint to expose supported extensions
To be discussed:
- Single endpoint returning a list of supported extensions
- Single endpoint returning a list of supported extensions with their status
- Endpoint to ask is a specific feature is supported (Not very efficient)
Server implementation status
supportExtensions field should be only part of the
ping endpoint response, to not bloat all other responses?
I don’t know, if we need to do a ping then we can also directly ask for the supported extension and handle error 404 since in all case we will do it after we know it’s supported.
If all servers report the type and version the field is probably not even needed since it’s more or less part of the extensions?
From what I see with other clients (DSub, Ultrasonic, substreamer), they send a
ping when registering the server to validate address/user/password. At this point you would get the
supportExtensions field and save it with the server information you already save.
Doesn’t Symfonium do this initial ping to validate address/user/password?
Yes I do amongst other tests, but servers are upgraded during their life time that will need to request the supported endpoints anyway again without running the wizard. Probably based on the fact that the server version have changed in any query return.
Anyway exposing the field in ping does not hurt and works for me.
Why not directly use the new endpoint to retrieve the extensions? Will this hurt some “old” servers?
It won’t hurt but might fill them with error in their logs that users would not understand. And some reverse proxy might have security around too many 404.