@Walaa: Those are all good feedback points that are appreciated. I realized that the capabilities probably add more complexity than necessary. As you mentioned, in the end we really want to know what endpoints a server supports.
I've created a new design doc and opened a separate discussion thread for that topic. Thanks Eduard On Tue, Aug 6, 2024 at 5:37 AM Walaa Eldin Moustafa <wa.moust...@gmail.com> wrote: > Catching up here. > > From Eduard's doc [1], it seems that at the end of the day, the > capability boils down to whether an end point is implemented by the > server or not. Therefore, I feel we could simplify things by skipping > the categorization/grouping (e.g., tables, views, udfs, etc) and just > allow servers to declare whether an end point is implemented or not. > We could have a discussion around how to assign identities to > endpoints. I think skipping the categorization has some benefits: > * It removes one concept that servers and client implementations need > to be aware of. It also removes one level of indirection. > * It transitively removes the "capability version" concept, since with > the capabilities solution, it seems within each category we should > group some APIs into versions. It is not clear what the process is > around creating versions and what group of APIs qualify as a version. > It sounds there will be a dedicated process to create those. > * It allows us to future-proof the concept of capabilities since it > will be clearly correlated with endpoints and we do not have to come > up with new terms for new capabilities and retro-fit them to existing > capabilities. > > I am trying to see if we could simplify how to think about > compatibility in Iceberg since there are quite a set of moving parts > such as Iceberg library version number, table format version number, > REST spec version number, REST endpoint root version number, etc, all > of those interacting with reader, writer, server versions (which is a > topic that I think is worth discussing but possibly in another > thread). > > Thanks, > Walaa. > > [1] > https://docs.google.com/document/d/1F1xh6SJhS-opgWRe1pPvWh01j8VHNHRocfCCFttKNf0/edit >
