Hi Eduard It looks good to me. I have a question however :)
Later, Imagine, we add UDF support in Iceberg. Does it mean that you will need to update REST Spec (ConfigResponse/capabilities) to add this capability ? For consistency, I think it makes sense as I don't think we often add new capability. And also as every REST server would have to implement it, /config is generic enough to add custom/new capabilities (but the client will have to deal with capability). Am I right? Thanks ! Regards JB On Thu, Jun 20, 2024 at 1:28 PM Eduard Tudenhoefner <etudenhoef...@apache.org> wrote: > > Hey everyone, > > I'd like to bring up the discussion around describing REST server > capabilities via the /config endpoint. > There is PR #9940 that describes the OpenAPI spec changes. > > Mainly we'd like to have a capabilities field in the ConfigResponse that > allows servers to indicate to clients which capabilities are being supported. > > So far we have the following capabilities: > > tables > views > remote-signing > vended-credentials > multi-table-commit > register-table > table-metrics > oauth2 > > > The general idea behind a capability is that if e.g. a server supports views, > then that server must implement all endpoints grouped under that capability. > It's worth noting that the /config endpoint is currently being implicit > (meaning that every REST server would have to implement it). > > One discussion point that came up during review is how we want to handle > capabilities and backwards compatibility and what the default capability > would be, since older servers don't know anything about capabilities (in such > a case we could assume that the default capabilities would be oauth2 / > tables). > > Are there any other capabilities that we'd like to include in the list? > > Eduard
