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

Reply via email to