Hey JB, If adding UDFs would require adding new endpoints, then you'd also add a *udf *capability when adding UDF support to the REST catalog. That way a client knows whether it's safe to call the UDF endpoints on a given server.
Eduard On Thu, Jun 20, 2024 at 1:59 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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 >
