The opposite is, as I expressed, that a client would _not_ use
functionality that worked before. In other words: the
capabilities-change would become a _breaking_ change - not backwards
compatible.
On 02.07.24 15:02, Eduard Tudenhöfner wrote:
I couldn't make it to the catalog sync meeting yesterday but I watched
the recording today (thanks for providing that).
The missing piece is how (new, capabilities-aware) clients handle
the case when a service does _not_ return the capabilities field
(absent). My proposal would be that a client should in this case
assume that all _currently_ existing capabilities are supported.
- tables: [1]
- views: [1]
- remote-signing: [1]
- multi-table-commit: [1]
- register-table: [1]
- table-metrics: [1]
- table-spec: [1,2]
- view-spec: [1,2]
The one thing I would like to add here is that the current PR uses the
*tables* capability (as version 1) as the default when a server
doesn't return *capabilities *but it might be also ok to include
*views *(as version 1) because the current client impl has /some/ code
to deal with errors in case endpoints don't exist.
Unless we agree that the currently existing functionality in the REST
spec is the *default* behavior to be assumed for older server, I'm not
sure about including *remote-signing / multi-table-commit /
register-table / table-metrics* as it has been indicated in earlier
comments on the PR/ML that not every REST server supports these.
That being said, we should discuss whether we want the *default*
behavior (when an older server doesn't send back *capabilities*) to be
a) *tables* (version 1) only
b) the currently existing functionality as defined in the REST spec
(as version 1)
On another note: Including *table-spec / view-spec* seems to be more
informative in its nature as I don't think a client would act
differently right now when seeing these.
Thanks
Eduard
--
Robert Stupp
@snazy
