Hi Eduard, That makes sense. Thanks.
Maybe we can already anticipate a little and add a "catalog-level versioning" capability as it's a feature supported by Nessie catalog for instance ? We can also imagine a more generic capability like "version scope". Regards JB On Thu, Jun 20, 2024 at 3:47 PM Eduard Tudenhoefner <etudenhoef...@apache.org> wrote: > > 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
