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
