Howdy folks, I implemented Alex's registry approach in this PR [1] to help move us forward. (Thanks, Alex!) It's a bit worse than expected because there is a hard dependency on the Generic Table REST APIs in the Spark client, but I hope we can handle that in a separate PR. Take a gander and see if that helps!
[1] - https://github.com/apache/polaris/pull/4926 Go community, Adam On Mon, Jun 29, 2026 at 11:50 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi all, > > While I appreciate Alex's suggestion, I’m concerned we might be > over-engineering this. > > Why not simply have dedicated endpoints for each purpose (OpenLineage, > Ossie, etc.) that are registered when their corresponding modules are > packaged? I don't see any issue with isolating these into dedicated APIs > per feature. > > Just my $0.02. > > Regards, > JB > > > On Mon, Jun 29, 2026 at 4:40 PM Russell Spitzer <[email protected] > > > wrote: > > > Moving toward Alex's suggestion of a pluggable "endpoint collector" > sounds > > good to me if we are going to keep > > creating new modules which need to register endpoints without having a > hard > > dependency on the core module. I'm > > not sure we really do need to make a lot of modules but it seems like > folks > > are more comfortable with that approach > > so Alex's suggestion seems like the right solution. > > > > > > > > On Thu, Jun 25, 2026 at 6:43 PM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi Yufei, > > > > > > > [...] keep the existing endpoint as the discovery contract and > > > > refactor the implementation behind it if needed. > > > > > > I tend to agree that it is reasonable to keep this behaviour at the API > > > level (while refactoring implementations to be pluggable, as Alex > > > suggested). > > > > > > My interpretation of the points raised earlier in this thread is that > > there > > > probably already exist clients that rely on the IRC config for Polaris > > > feature discovery. It would be overkill to break those clients now. > > > > > > Ideally, we may want to consider a different capability discovery > > endpoint > > > (config) in Polaris that would be generalizable to all APIs (including > > > sibling base URIs), but that is beyond the scope of this thread, I > guess. > > > It's something to keep in mind for future enhancements. > > > > > > Cheers, > > > Dmitri. > > > > > > On Thu, Jun 25, 2026 at 7:00 PM Yufei Gu <[email protected]> wrote: > > > > > > > Hi Alex, > > > > > > > > 1) Extract the getConfig() implementation from IcebergCatalogHandler > > > > > and move it to a dedicated handler, since it's now much more than > > just > > > > > the IRC config endpoint. > > > > > > > > 2) Expose the same content under a new, Polaris-specific endpoint, > and > > > > > gradually migrate clients. > > > > > 3) Develop an "endpoint collector" system, comparable to our > > > > > production readiness checks, allowing modules to advertise their > > > > > endpoints via CDI producer methods to be aggregated into a > > > > > ConfigResponse object at runtime. > > > > > > > > > > > > Thanks for the suggestions. I hope I can agree with all of them. The > > > > current endpoint is working today, and clients already rely on it for > > > > capability discovery. I don't see what benefit justifies introducing > a > > > new > > > > endpoint and migrating existing clients. That's a significant cost > for > > > very > > > > little practical gain. > > > > > > > > I'm all for improving the internal implementation. If moving > > getConfig() > > > > out of IcebergCatalogHandler or introducing an endpoint collector > makes > > > the > > > > codebase cleaner, that's fine. But those are implementation details. > > They > > > > don't require changing the public API or introducing a migration > path. > > > > > > > > I'd rather keep the existing endpoint as the discovery contract and > > > > refactor the implementation behind it if needed. > > > > > > > > Yufei > > > > > > > > > > > > On Wed, Jun 24, 2026 at 9:58 AM Dmitri Bourlatchkov < > [email protected]> > > > > wrote: > > > > > > > > > Hi Alex, > > > > > > > > > > I am not sure if Open Lineage and OSI endpoints would / could adopt > > > > > the same pattern and be rooted at /api/catalog/xyz while > advertising > > > > > /xyz. > > > > > > > > > > But maybe they don't have to? Endpoints are so far largely > > > > > informational. The IRC client, at least, does not check the > endpoint > > > > > path validity nor creates a full URI, it simply compares known > > > > > endpoint paths with the (logical) endpoint path being invoked. In > > > > > theory, it looks like the endpoint path can be any string as long > as > > > > > it's a distinctive, well-known one. > > > > > > > > > > > > > > > Yes, this can work in practice. > > > > > > > > > > I wonder what the Open Lineage and OSI proposal authors think about > > > this. > > > > > > > > > > Are those endpoints envisioned to be part of IRC config responses? > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Wed, Jun 24, 2026 at 11:55 AM Alexandre Dutra < > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > > The endpoints in the IRC config must logically be relative to > the > > > IRC > > > > > > catalog base URI, which has the path of "/api/catalog". > > > > > > > > > > > > That's a good point. > > > > > > > > > > > > Both the policy and the generic table APIs currently share the > same > > > > > > path prefix with IRC: they are both rooted at > > > > > > /api/catalog/polaris/v1/{prefix}, while IRC is rooted at > > > > > > /api/catalog/v1/{prefix}. The /api/catalog/ portion is indeed > > common > > > > > > to all of them, and currently, endpoints are all advertised > > relative > > > > > > to that base. > > > > > > > > > > > > I am not sure if Open Lineage and OSI endpoints would / could > adopt > > > > > > the same pattern and be rooted at /api/catalog/xyz while > > advertising > > > > > > /xyz. > > > > > > > > > > > > But maybe they don't have to? Endpoints are so far largely > > > > > > informational. The IRC client, at least, does not check the > > endpoint > > > > > > path validity nor creates a full URI, it simply compares known > > > > > > endpoint paths with the (logical) endpoint path being invoked. In > > > > > > theory, it looks like the endpoint path can be any string as long > > as > > > > > > it's a distinctive, well-known one. > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > On Wed, Jun 24, 2026 at 4:54 PM Dmitri Bourlatchkov < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > Your plan sounds good to me with one caveat :) > > > > > > > > > > > > > > The endpoints in the IRC config must logically be relative to > the > > > IRC > > > > > > > catalog base URI, which has the path of "/api/catalog". > > > > > > > > > > > > > > While this holds for the current endpoints in that config, I am > > not > > > > > sure > > > > > > it > > > > > > > will hold for future Polaris endpoints. > > > > > > > > > > > > > > Let's review at least the endpoints from the current WIP > features > > > in > > > > > this > > > > > > > context. > > > > > > > > > > > > > > What Open Lineage and OSI endpoints are proposed for inclusion > > into > > > > the > > > > > > IRC > > > > > > > config? > > > > > > > > > > > > > > Thanks, > > > > > > > Dmitri. > > > > > > > > > > > > > > On Wed, Jun 24, 2026 at 10:37 AM Alexandre Dutra < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > Regarding the correctness of the current implementation, I am > > > > aligned > > > > > > > > with Dmitri: repurposing the IRC config endpoint as a > universal > > > > > > > > Polaris capability discovery tool looks like a > > misappropriation. > > > > > > > > > > > > > > > > Furthermore, I also interpret the expression "endpoints > > supported > > > > by > > > > > > > > the server" as being strictly limited to those defined within > > the > > > > IRC > > > > > > > > specification. This likely alludes to versioning > discrepancies > > > > > between > > > > > > > > clients and servers regarding the IRC spec itself, > specifically > > > for > > > > > > > > newer endpoints that might not be fully implemented yet. It > > seems > > > > > > > > illogical for a specification to permit the inclusion of > > entirely > > > > > > > > extraneous endpoints (can I add a weather forecast endpoint > > > then?). > > > > > > > > Additionally, the CatalogConfig schema is inherently an > Iceberg > > > > type > > > > > > > > and requires the iceberg-core jar on the classpath. > > > > > > > > > > > > > > > > That said, I admit that Russell has a point: the current > system > > > is > > > > > > > > functional, so why change it? While there may not be an > urgent > > > need > > > > > > > > for change, I also think that the polaris-runtime-service > > module > > > is > > > > > > > > trending toward becoming a monolith; incorporating non-IRC > > > > > > > > functionality into IcebergCatalogHandler exacerbates this > > issue. > > > > > > > > Ideally, I would love to split that module and isolate > > > > > > > > Polaris-specific APIs into separate modules with a clean > > purpose. > > > > > > > > Today it's OK, but continually adding disparate APIs to > > > > > > > > polaris-runtime-service is not a sustainable practice. > > > > > > > > > > > > > > > > If we agree to improve things, my suggestions are as follows: > > > > > > > > > > > > > > > > 1) Extract the getConfig() implementation from > > > > IcebergCatalogHandler > > > > > > > > and move it to a dedicated handler, since it's now much more > > than > > > > > just > > > > > > > > the IRC config endpoint. > > > > > > > > > > > > > > > > 2) Expose the same content under a new, Polaris-specific > > > endpoint, > > > > > and > > > > > > > > gradually migrate clients. > > > > > > > > > > > > > > > > 3) Develop an "endpoint collector" system, comparable to our > > > > > > > > production readiness checks, allowing modules to advertise > > their > > > > > > > > endpoints via CDI producer methods to be aggregated into a > > > > > > > > ConfigResponse object at runtime. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Alex > > > > > > > > > > > > > > > > On Wed, Jun 24, 2026 at 10:02 AM Robert Stupp < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > > > Thanks, that helps clarify the disagreement. > > > > > > > > > > > > > > > > > > I agree there is a use case for Polaris-aware clients > > > discovering > > > > > > Polaris > > > > > > > > > capabilities. I do not think that is disputed. > > > > > > > > > > > > > > > > > > The part I am still missing is whether we are intentionally > > > > > defining > > > > > > the > > > > > > > > > existing IRC config response as the Polaris-wide capability > > > > > discovery > > > > > > > > > contract. > > > > > > > > > If yes, I think we should state that explicitly and > document > > it > > > > as > > > > > a > > > > > > > > > Polaris extension, including how optional modules > contribute > > > > > > > > > endpoint/capability metadata without coupling the IRC > service > > > > code > > > > > to > > > > > > > > every > > > > > > > > > feature. > > > > > > > > > > > > > > > > > > If no, then I think new non-IRC APIs should not rely on the > > IRC > > > > > > config > > > > > > > > > response for discovery by default. > > > > > > > > > > > > > > > > > > So for me the decision is less about whether clients can > > ignore > > > > > > unknown > > > > > > > > > endpoints, and more about whether `/api/catalog/v1/config` > is > > > > > > > > intentionally > > > > > > > > > becoming Polaris service discovery. > > > > > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 24, 2026 at 12:55 AM Dmitri Bourlatchkov < > > > > > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Yun, > > > > > > > > > > > > > > > > > > > > Thanks for sharing your perspective. It is very helpful! > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 4:42 PM yun zou < > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Sorry, I haven't had a chance to read through the > entire > > > > thread > > > > > > yet. > > > > > > > > From > > > > > > > > > > > what I can tell, the main question is whether we should > > > > return > > > > > > > > non-IRC > > > > > > > > > > > endpoints in the IRC configuration. > > > > > > > > > > > > > > > > > > > > > > From my perspective, Polaris is evolving beyond IRC and > > > > > becoming > > > > > > a > > > > > > > > > > superset > > > > > > > > > > > of Iceberg while still remaining Iceberg-native. For > > > concepts > > > > > > that > > > > > > > > are > > > > > > > > > > > shared between IRC and non-IRC functionality, it's > > > generally > > > > > > better > > > > > > > > to > > > > > > > > > > > reuse the same abstractions rather than introduce > > separate > > > > > ones. > > > > > > > > > > Namespaces > > > > > > > > > > > are a good example of this. Reusing common concepts > helps > > > > > reduce > > > > > > > > > > > maintenance overhead and lowers the onboarding burden > for > > > > > users. > > > > > > > > > > > > > > > > > > > > > > Regarding the configuration, I view it as a generic > > > mechanism > > > > > for > > > > > > > > > > > describing the server's overall configuration and > > > > capabilities. > > > > > > In > > > > > > > > > > > particular, the endpoints section should simply > indicate > > > all > > > > > > > > endpoints > > > > > > > > > > > currently supported by Polaris. Clients can then > > determine > > > > > which > > > > > > > > > > operations > > > > > > > > > > > are available based on the returned configuration and > > > > > advertised > > > > > > > > > > > capabilities. > > > > > > > > > > > > > > > > > > > > > > For example, the Polaris Spark client may recognize > from > > > the > > > > > > > > > > configuration > > > > > > > > > > > that generic tables are supported by the server and > > choose > > > to > > > > > > > > interact > > > > > > > > > > with > > > > > > > > > > > the corresponding endpoints. In contrast, the Iceberg > > Spark > > > > > > client > > > > > > > > may > > > > > > > > > > > choose to interact only with Iceberg endpoints. In both > > > > cases, > > > > > > the > > > > > > > > > > > configuration serves as a capability discovery > mechanism, > > > > while > > > > > > > > > > individual > > > > > > > > > > > clients decide which capabilities they want to consume. > > > > > > > > > > > > > > > > > > > > > > As Russell mentioned, I don't see a strong reason to > > > > introduce > > > > > a > > > > > > > > separate > > > > > > > > > > > getConfig API solely to distinguish between IRC and > > non-IRC > > > > > > > > endpoints. > > > > > > > > > > > > > > > > > > > > > > Unless there is a specific compatibility or security > > > concern, > > > > > > > > exposing > > > > > > > > > > the > > > > > > > > > > > full set of supported endpoints through the existing > > > > > > configuration > > > > > > > > > > > mechanism seems like the simpler, more extensible > > approach. > > > > > > > > > > > > > > > > > > > > > > One question I have is: if we choose not to expose > these > > > > > > capabilities > > > > > > > > > > > through the existing getConfig response, what is the > > > proposed > > > > > > > > mechanism > > > > > > > > > > for > > > > > > > > > > > future clients to discover the capabilities of a > deployed > > > > > Polaris > > > > > > > > > > service? > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > > Yun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 12:57 PM Dmitri Bourlatchkov < > > > > > > > > [email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Adnan, > > > > > > > > > > > > > > > > > > > > > > > > Does Polaris gain anything from separating these two > > > > > getConfig > > > > > > APIs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not exactly sure what you mean by "separating". > My > > > > > > proposal is > > > > > > > > > > simply > > > > > > > > > > > > to remove non-IRC endpoints from IRC config. > > > > > > > > > > > > > > > > > > > > > > > > Nonetheless, in either case, the benefit will be that > > IRC > > > > API > > > > > > > > services > > > > > > > > > > in > > > > > > > > > > > > Polaris (server-side) will not have a dependency on > > > other, > > > > > > non-IRC > > > > > > > > REST > > > > > > > > > > > > APIs. > > > > > > > > > > > > > > > > > > > > > > > > More concretely, I do not mind existing non-IRC > > endpoints > > > > in > > > > > > the > > > > > > > > IRC > > > > > > > > > > > > config. However, I think Polaris should maintain this > > > > > > distinction > > > > > > > > for > > > > > > > > > > new > > > > > > > > > > > > APIs. This will simplify the modular design for new > > > > features. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 2:37 PM Adnan Hemani via dev > < > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > I think Yufei and Russell explained above that we > can > > > > > either: > > > > > > > > > > > > > > > > > > > > > > > > > > * Continue doing what we are doing today - IRC > > clients > > > > see > > > > > > (and > > > > > > > > > > ignore) > > > > > > > > > > > > > endpoints they will not action upon. OR > > > > > > > > > > > > > * Separate it out into two different getConfig > APIs - > > > one > > > > > for > > > > > > > > > > Polaris, > > > > > > > > > > > > one > > > > > > > > > > > > > for IRC. In this case, the Polaris getConfig would > > be a > > > > > > strict > > > > > > > > > > superset > > > > > > > > > > > > of > > > > > > > > > > > > > the IRC API - and the Polaris-specific clients > would > > > use > > > > > the > > > > > > > > Polaris > > > > > > > > > > > > > getConfig API. > > > > > > > > > > > > > > > > > > > > > > > > > > My understanding of why Russell brought up the > point > > > > > > regarding > > > > > > > > "Can > > > > > > > > > > > > non-IRC > > > > > > > > > > > > > endpoints be added to the IRC config response > without > > > > > > breaking > > > > > > > > > > > clients?" > > > > > > > > > > > > > is: There is clearly a use case for Polaris clients > > > using > > > > > the > > > > > > > > > > getConfig > > > > > > > > > > > > API > > > > > > > > > > > > > - so the real question, in my opinion, is what is > the > > > > > > benefit of > > > > > > > > > > > creating > > > > > > > > > > > > > two `getConfig` APIs versus continuing our current > > > > approach > > > > > > which > > > > > > > > > > > reduces > > > > > > > > > > > > > code paths and complexity? Does Polaris gain > anything > > > > from > > > > > > > > separating > > > > > > > > > > > > these > > > > > > > > > > > > > two getConfig APIs other than establishing a > strict, > > > > > > principled > > > > > > > > > > stance > > > > > > > > > > > on > > > > > > > > > > > > > our interpretation of the IRC spec text? > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > Adnan Hemani > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 9:50 AM Robert Stupp < > > > > > [email protected] > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think we should separate two questions: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Can non-IRC endpoints be added to the IRC > config > > > > > > response > > > > > > > > > > without > > > > > > > > > > > > > > breaking clients? > > > > > > > > > > > > > > 2. What can a normal Iceberg REST client actually > > do > > > > with > > > > > > that > > > > > > > > > > > > > information? > > > > > > > > > > > > > > > > > > > > > > > > > > > > The first question only tells us whether the > > behavior > > > > is > > > > > > > > tolerated. > > > > > > > > > > > > > > It does not establish that the IRC config > response > > is > > > > the > > > > > > right > > > > > > > > > > > > contract > > > > > > > > > > > > > > for Polaris-wide capability discovery. > > > > > > > > > > > > > > > > > > > > > > > > > > > > For a normal IRC client, I do not see a concrete > > use > > > > case > > > > > > for > > > > > > > > > > > > > OpenLineage, > > > > > > > > > > > > > > OSI, generic-table, or policy endpoints in that > > > > response. > > > > > > > > > > > > > > A Polaris-aware client may need discovery, but > that > > > > > sounds > > > > > > like > > > > > > > > > > > Polaris > > > > > > > > > > > > > > capability discovery, not IRC capability > discovery. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So what is the concrete use case for exposing > those > > > > > > endpoints > > > > > > > > to > > > > > > > > > > > normal > > > > > > > > > > > > > IRC > > > > > > > > > > > > > > clients? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 3:26 PM Dmitri > > Bourlatchkov < > > > > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The community has already decided to reuse > the > > > IRC > > > > > > config > > > > > > > > > > > endpoint > > > > > > > > > > > > > for > > > > > > > > > > > > > > > capability discovery > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you give a link to that decision? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 9:45 PM Yufei Gu < > > > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yet, no one answered my second question > from > > > the > > > > > > initial > > > > > > > > > > email. > > > > > > > > > > > > > That > > > > > > > > > > > > > > > is: > > > > > > > > > > > > > > > > why do we need to expose non-IRC endpoints in > > the > > > > IRC > > > > > > > > config > > > > > > > > > > > > response > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > the first place? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies if I didn't explain this clearly in > > my > > > > > > earlier > > > > > > > > email. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With Polaris, you can use a pure IRC client, > or > > > you > > > > > can > > > > > > > > use a > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > > client that leverages Polaris specific > > > capabilities > > > > > > such as > > > > > > > > > > > generic > > > > > > > > > > > > > > > tables > > > > > > > > > > > > > > > > and policies in addition to IRC > functionality. > > > The > > > > > > > > community > > > > > > > > > > has > > > > > > > > > > > > > > already > > > > > > > > > > > > > > > > decided to reuse the IRC config endpoint for > > > > > capability > > > > > > > > > > > discovery. > > > > > > > > > > > > I > > > > > > > > > > > > > > > shared > > > > > > > > > > > > > > > > an example from the Polaris Spark client > > > > previously, > > > > > > but > > > > > > > > I'll > > > > > > > > > > > > repeat > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > here because it illustrates the point well. > > Note > > > > that > > > > > > the > > > > > > > > > > client > > > > > > > > > > > > > > supports > > > > > > > > > > > > > > > > both Iceberg tables and generic tables: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > public List<TableIdentifier> > > > > > > listGenericTables(Namespace > > > > > > > > ns) { > > > > > > > > > > > > > > > > Endpoint.check(endpoints, > > > > > > > > > > > > > PolarisEndpoints.V1_LIST_GENERIC_TABLES); > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this model, the config endpoint acts as a > > > > > capability > > > > > > > > > > discovery > > > > > > > > > > > > > > > > mechanism. Standard IRC clients can simply > > ignore > > > > > > endpoints > > > > > > > > > > they > > > > > > > > > > > do > > > > > > > > > > > > > not > > > > > > > > > > > > > > > > recognize, while Polaris aware clients can > use > > > the > > > > > > > > additional > > > > > > > > > > > > > > information > > > > > > > > > > > > > > > > to enable Polaris specific functionality. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also think Adam made a good point. The > > > > > > > > /api/catalog/v1/config > > > > > > > > > > > > > > endpoint > > > > > > > > > > > > > > > > returns both IRC and Polaris capabilities. > > > > Otherwise, > > > > > > we > > > > > > > > need > > > > > > > > > > to > > > > > > > > > > > > > > > introduce > > > > > > > > > > > > > > > > a separate Polaris-specific discovery > endpoint, > > > > > > requiring > > > > > > > > > > clients > > > > > > > > > > > > to > > > > > > > > > > > > > > > query > > > > > > > > > > > > > > > > and manage two different capability sources. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 5:28 PM Adnan Hemani > > via > > > > dev > > > > > < > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ah yes, my mistake. But I think a similar > > point > > > > > > exists: > > > > > > > > Does > > > > > > > > > > > the > > > > > > > > > > > > > > > service > > > > > > > > > > > > > > > > > need to know about all new endpoint > > > information? > > > > > Can > > > > > > we > > > > > > > > not > > > > > > > > > > > make > > > > > > > > > > > > it > > > > > > > > > > > > > > > dumb > > > > > > > > > > > > > > > > > and gate on a server-wide feature flag or > > > > something > > > > > > > > similar? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Adnan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 5:02 PM Dmitri > > > > > Bourlatchkov < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Adnan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You might have misinterpreted my message. > > My > > > > > point > > > > > > was > > > > > > > > > > about > > > > > > > > > > > > the > > > > > > > > > > > > > > > server > > > > > > > > > > > > > > > > > > (service) side, not client side. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 7:58 PM Adnan > > Hemani > > > > via > > > > > > dev < > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For example, if we are to expose Open > > > > Lineage > > > > > > or > > > > > > > > OSI > > > > > > > > > > > > > endpoints > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > IRC > > > > > > > > > > > > > > > > > > > config, the IRC service code will have > to > > > be > > > > > > aware > > > > > > > > of OL > > > > > > > > > > / > > > > > > > > > > > > OSI > > > > > > > > > > > > > > > > modules. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't agree with this statement; the > > IRC > > > > > > client is > > > > > > > > > > always > > > > > > > > > > > > > free > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > disregard any of these > endpoints/modules. > > > > > > Returning > > > > > > > > this > > > > > > > > > > > > > > > information > > > > > > > > > > > > > > > > > does > > > > > > > > > > > > > > > > > > > not force a client to take any action > > based > > > > on > > > > > > this > > > > > > > > extra > > > > > > > > > > > > > > endpoint > > > > > > > > > > > > > > > > > > > information. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do agree that if this forced the IRC > > > client > > > > > to > > > > > > be > > > > > > > > > > > > > fundamentally > > > > > > > > > > > > > > > > > altered > > > > > > > > > > > > > > > > > > > because of these additional endpoints, > > then > > > > > that > > > > > > > > would > > > > > > > > > > be a > > > > > > > > > > > > > > > > significant > > > > > > > > > > > > > > > > > > > issue. But as Russell stated above, > "what > > > > would > > > > > > > > actually > > > > > > > > > > > > break > > > > > > > > > > > > > if > > > > > > > > > > > > > > > > > someone > > > > > > > > > > > > > > > > > > > interpreted the spec this way?" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > > Adnan Hemani > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 3:30 PM Dmitri > > > > > > Bourlatchkov < > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Russell, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your points sound reasonable to me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yet, noone answered my second > question > > > from > > > > > my > > > > > > > > initial > > > > > > > > > > > > email. > > > > > > > > > > > > > > > That > > > > > > > > > > > > > > > > > is: > > > > > > > > > > > > > > > > > > > why > > > > > > > > > > > > > > > > > > > > do we need to expose non-IRC > endpoints > > in > > > > the > > > > > > IRC > > > > > > > > > > config > > > > > > > > > > > > > > response > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > first place? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding the maintainability > aspect, I > > > see > > > > > > this > > > > > > > > > > > becoming a > > > > > > > > > > > > > > more > > > > > > > > > > > > > > > > > > > > substantial concern if it evolves > into > > a > > > > > > > > > > self-sustaining > > > > > > > > > > > > > > pattern. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For example, if we are to expose Open > > > > Lineage > > > > > > or > > > > > > > > OSI > > > > > > > > > > > > > endpoints > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > IRC > > > > > > > > > > > > > > > > > > > > config, the IRC service code will > have > > to > > > > be > > > > > > aware > > > > > > > > of > > > > > > > > > > OL > > > > > > > > > > > / > > > > > > > > > > > > > OSI > > > > > > > > > > > > > > > > > > modules. I > > > > > > > > > > > > > > > > > > > > think this dependency is conceptually > > > > > > incorrect. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not so much mind existing > non-IRC > > > > > > endpoints > > > > > > > > in the > > > > > > > > > > > IRC > > > > > > > > > > > > > > > config, > > > > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > > > > > extending this to new APIs feels like > > an > > > > > > > > anti-pattern > > > > > > > > > > to > > > > > > > > > > > > me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 5:46 PM > Russell > > > > > > Spitzer < > > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From a very pragmatic point of > view, > > > I'm > > > > > not > > > > > > sure > > > > > > > > > > what > > > > > > > > > > > > we'd > > > > > > > > > > > > > > > gain > > > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > > > > > > separate > > > > > > > > > > > > > > > > > > > > > configuration mechanisms. We > already > > > have > > > > > > one and > > > > > > > > > > it's > > > > > > > > > > > > > worked > > > > > > > > > > > > > > > > well > > > > > > > > > > > > > > > > > so > > > > > > > > > > > > > > > > > > > > far, > > > > > > > > > > > > > > > > > > > > > do we have a compelling reason to > > swap > > > > > right > > > > > > now? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As best I can tell, the worst case > is > > > > that > > > > > > the > > > > > > > > IRC > > > > > > > > > > spec > > > > > > > > > > > > > later > > > > > > > > > > > > > > > > > > tightens > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > semantics > > > > > > > > > > > > > > > > > > > > > of the endpoints field, making our > > > extra > > > > > > entries > > > > > > > > > > > > > > non-compliant. > > > > > > > > > > > > > > > > In > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > > situation > > > > > > > > > > > > > > > > > > > > > we'd have to change our response, > > add a > > > > > > > > > > > Polaris-specific > > > > > > > > > > > > > > > > > > > config/discovery > > > > > > > > > > > > > > > > > > > > > endpoint, and > > > > > > > > > > > > > > > > > > > > > have our clients move over to it. > But > > > > > that's > > > > > > > > exactly > > > > > > > > > > > the > > > > > > > > > > > > > work > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > > proposal > > > > > > > > > > > > > > > > > > > > > is asking us to do today > > > > > > > > > > > > > > > > > > > > > so we would be taking same burden > now > > > > > > instead of > > > > > > > > > > > > > potentially > > > > > > > > > > > > > > > > never. > > > > > > > > > > > > > > > > > > I'd > > > > > > > > > > > > > > > > > > > > > rather defer > > > > > > > > > > > > > > > > > > > > > it until something concrete forces > > our > > > > > hand. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The one counter I can see is that > > > > > decoupling > > > > > > gets > > > > > > > > > > > harder > > > > > > > > > > > > as > > > > > > > > > > > > > > > more > > > > > > > > > > > > > > > > > > > clients > > > > > > > > > > > > > > > > > > > > > adopt it. But > > > > > > > > > > > > > > > > > > > > > since the Polaris endpoints are > > already > > > > > > > > namespaced > > > > > > > > > > > > > > > > (/polaris/...), > > > > > > > > > > > > > > > > > > > > lifting > > > > > > > > > > > > > > > > > > > > > them into a separate endpoint > > > > > > > > > > > > > > > > > > > > > later stays mechanical, so I don't > > > think > > > > > > we're > > > > > > > > > > > > > meaningfully > > > > > > > > > > > > > > > > > cheaper > > > > > > > > > > > > > > > > > > > > doing > > > > > > > > > > > > > > > > > > > > > it now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to gently point out that > it > > > > > doesn't > > > > > > feel > > > > > > > > > > > > > especially > > > > > > > > > > > > > > > > > > important > > > > > > > > > > > > > > > > > > > > > whether the exact wording > > > > > > > > > > > > > > > > > > > > > or original intent of the spec > > supports > > > > > what > > > > > > > > we're > > > > > > > > > > > doing. > > > > > > > > > > > > > The > > > > > > > > > > > > > > > > > > > discussion > > > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > starting to feel > > > > > > > > > > > > > > > > > > > > > like a legalistic reading of the > spec > > > > > rather > > > > > > > > than a > > > > > > > > > > > focus > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > concrete > > > > > > > > > > > > > > > > > > > > > impact. I'd suggest we focus > > > > > > > > > > > > > > > > > > > > > on arguments like "what would > > actually > > > > > break > > > > > > if > > > > > > > > > > someone > > > > > > > > > > > > > > > > interpreted > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > spec this way?" > > > > > > > > > > > > > > > > > > > > > rather than "what was the original > > > intent > > > > > of > > > > > > the > > > > > > > > > > text?" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 3:23 PM > Adnan > > > > > Hemani > > > > > > via > > > > > > > > dev > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think you and I view the same > > > > statement > > > > > > very > > > > > > > > > > > > > differently > > > > > > > > > > > > > > - > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > > definitely > > > > > > > > > > > > > > > > > > > > > > don't think it's "pretty clear > that > > > the > > > > > > scope > > > > > > > > of > > > > > > > > > > the > > > > > > > > > > > > data > > > > > > > > > > > > > > > > > returned > > > > > > > > > > > > > > > > > > > > under > > > > > > > > > > > > > > > > > > > > > > that type is limited to the API > > > defined > > > > > by > > > > > > the > > > > > > > > > > > spec". I > > > > > > > > > > > > > see > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > > way: > > > > > > > > > > > > > > > > > > > > > if > > > > > > > > > > > > > > > > > > > > > > this statement truly meant ONLY > IRC > > > > > > endpoints, > > > > > > > > the > > > > > > > > > > > spec > > > > > > > > > > > > > > would > > > > > > > > > > > > > > > > > > > > explicitly > > > > > > > > > > > > > > > > > > > > > > use the words "IRC spec > endpoints". > > > The > > > > > > > > absence of > > > > > > > > > > > > > > > > clarification > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > any > > > > > > > > > > > > > > > > > > > > > > specification rarely means you > > should > > > > > > > > > > > > > > > "read-between-the-lines" > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > assume > > > > > > > > > > > > > > > > > > > > > > the writer's "intent". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will look into Iceberg mailing > > list > > > > > > threads > > > > > > > > and > > > > > > > > > > PRs > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > background > > > > > > > > > > > > > > > > > > > > > > information to clarify things. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > > > > > Adnan Hemani > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 12:27 PM > > > Dmitri > > > > > > > > > > Bourlatchkov > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > HI Adnan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IRC spec defines a "type" > for > > > the > > > > > > config > > > > > > > > > > > > response. > > > > > > > > > > > > > A > > > > > > > > > > > > > > > > > property > > > > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > > > > "type" is a list of "endpoints > > > > > supported > > > > > > by > > > > > > > > the > > > > > > > > > > > > > server". > > > > > > > > > > > > > > > > There > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > no > > > > > > > > > > > > > > > > > > > > > > > statement about generalizing > > those > > > > > > endpoints > > > > > > > > to > > > > > > > > > > > > non-IRC > > > > > > > > > > > > > > > APIs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Therefore, I think it is pretty > > > clear > > > > > > that > > > > > > > > the > > > > > > > > > > > scope > > > > > > > > > > > > of > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > data > > > > > > > > > > > > > > > > > > > > > returned > > > > > > > > > > > > > > > > > > > > > > > under that type is limited to > the > > > API > > > > > > > > defined by > > > > > > > > > > > the > > > > > > > > > > > > > > spec, > > > > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > IRC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let's expand this discussion a > > bit. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What is the rationale for > > returning > > > > > > non-IRC > > > > > > > > > > > endpoints > > > > > > > > > > > > > in > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > IRC > > > > > > > > > > > > > > > > > > > > config > > > > > > > > > > > > > > > > > > > > > > > response? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 22, 2026 at 3:21 PM > > > Adnan > > > > > > Hemani > > > > > > > > via > > > > > > > > > > > dev > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Hi Dmitri, > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> I'm not sure where you are > > > assuming > > > > > that > > > > > > > > > > > "endpoints" > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > refers > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > >> Iceberg > > > > > > > > > > > > > > > > > > > > > > >> endpoints in the IRC spec. Do > > you > > > > have > > > > > > any > > > > > > > > thing > > > > > > > > > > > you > > > > > > > > > > > > > can > > > > > > > > > > > > > > > > point > > > > > > > > > > > > > > > > > > us > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > >> regarding this? > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> Best, > > > > > > > > > > > > > > > > > > > > > > >> Adnan Hemani > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> On Mon, Jun 22, 2026 at > 12:18 PM > > > > > Dmitri > > > > > > > > > > > > Bourlatchkov < > > > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> > Hi Adam, > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > #1 - Is GET ' > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://localhost:8181/api/catalog/v1/config?warehouse=polaris > > > > > > > > > > > > > > > > > > ' > > > > > > > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > > > > > > >> > an Iceberg Catalog concept? > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > My interpretation is YES, > > > because > > > > > the > > > > > > > > payload > > > > > > > > > > of > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > response > > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > > >> defined > > > > > > > > > > > > > > > > > > > > > > >> > by the IRC API spec [1]. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > I believe one can reasonably > > > > assume > > > > > > that > > > > > > > > the > > > > > > > > > > > > > statement > > > > > > > > > > > > > > > > > > > "endpoints > > > > > > > > > > > > > > > > > > > > > > >> supported > > > > > > > > > > > > > > > > > > > > > > >> > by the server" is scoped > only > > to > > > > the > > > > > > IRC > > > > > > > > API > > > > > > > > > > > > itself. > > > > > > > > > > > > > > > > There's > > > > > > > > > > > > > > > > > > no > > > > > > > > > > > > > > > > > > > > > > >> provision > > > > > > > > > > > > > > > > > > > > > > >> > in that spec about covering > > all > > > > > > possible > > > > > > > > APIs. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > That said, I'd be happy to > > > discuss > > > > > how > > > > > > > > clients > > > > > > > > > > > can > > > > > > > > > > > > > > > > discover > > > > > > > > > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > > > > > > > > >> > features in general without > > > > > > overloading > > > > > > > > > > existing > > > > > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > [1] > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/iceberg/blob/apache-iceberg-1.11.0/open-api/rest-catalog-open-api.yaml#L105 > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > On Mon, Jun 22, 2026 at > > 2:52 PM > > > > Adam > > > > > > > > > > Christian < > > > > > > > > > > > > > > > > > > > > > > >> > > > > [email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > I agree with both Yufei & > > > > Dmitri: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > #1 - It seems like > improper > > > > > coupling > > > > > > > > for an > > > > > > > > > > > > > Iceberg > > > > > > > > > > > > > > > REST > > > > > > > > > > > > > > > > > > > Catalog > > > > > > > > > > > > > > > > > > > > > > >> config > > > > > > > > > > > > > > > > > > > > > > >> > to > > > > > > > > > > > > > > > > > > > > > > >> > > return a configuration > > > unrelated > > > > > to > > > > > > > > Iceberg. > > > > > > > > > > > > > > > > > > > > > > >> > > #2 - Polaris is a superset > > of > > > an > > > > > > Iceberg > > > > > > > > > > REST > > > > > > > > > > > > > > Catalog. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > So, in my opinion, the > > > question > > > > is > > > > > > more > > > > > > > > > > aptly > > > > > > > > > > > > > framed > > > > > > > > > > > > > > > as > > > > > > > > > > > > > > > > > two > > > > > > > > > > > > > > > > > > > > > > questions: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > #1 - Is GET ' > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://localhost:8181/api/catalog/v1/config?warehouse=polaris > > > > > > > > > > > > > > > > > > > > > > >> > > ' > > > > > > > > > > > > > > > > > > > > > > >> > > only an Iceberg Catalog > > > concept? > > > > > > > > > > > > > > > > > > > > > > >> > > #2 - Should GET ' > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://localhost:8181/api/catalog/v1/config?warehouse=polaris > > > > > > > > > > > > > > > > > > > ' > > > > > > > > > > > > > > > > > > > > > > return > > > > > > > > > > > > > > > > > > > > > > >> > > additional endpoints? > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > I believe that the answer > to > > > #1 > > > > is > > > > > > no, > > > > > > > > but > > > > > > > > > > > that > > > > > > > > > > > > > > > requires > > > > > > > > > > > > > > > > > > > changes > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > > > > > >> > > codebase. I believe the > > answer > > > > to > > > > > > #2 is > > > > > > > > yes. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > Based on the codebase, we > > are > > > > > > exposing > > > > > > > > > > several > > > > > > > > > > > > > > > endpoints > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > > > > >> > > configuration API which > are > > > not > > > > > > Iceberg > > > > > > > > > > > > endpoints. > > > > > > > > > > > > > > For > > > > > > > > > > > > > > > > > > > example, > > > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > >> > > Generic Tables case, it is > > > > > > explicitly > > > > > > > > not > > > > > > > > > > > > Iceberg. > > > > > > > > > > > > > > In > > > > > > > > > > > > > > > my > > > > > > > > > > > > > > > > > > > > opinion, > > > > > > > > > > > > > > > > > > > > > > >> this is > > > > > > > > > > > > > > > > > > > > > > >> > > alright because our API > > > > > > specification > > > > > > > > only > > > > > > > > > > > says > > > > > > > > > > > > > > > > > > "Configuration > > > > > > > > > > > > > > > > > > > > > API," > > > > > > > > > > > > > > > > > > > > > > >> not > > > > > > > > > > > > > > > > > > > > > > >> > > "Iceberg Configuration > API." > > > > Yes, > > > > > > it is > > > > > > > > > > > > > > > > > Iceberg-compatible, > > > > > > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > > >> not > > > > > > > > > > > > > > > > > > > > > > >> > > Iceberg-centric. This > > > retrieves > > > > > the > > > > > > > > > > > > configuration > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > Catalog; > > > > > > > > > > > > > > > > > > > > > > >> > > regardless of whether it > is > > an > > > > > > Iceberg > > > > > > > > > > > Catalog. > > > > > > > > > > > > > Now, > > > > > > > > > > > > > > > if > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > > truly > > > > > > > > > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > > > > > > > > > >> > > superset, it implies that > > > > > > > > > > > > > IcebergCatalogHandler.java > > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > > > > > > > > handle > > > > > > > > > > > > > > > > > > > > > > >> > > returning the > configuration. > > > > > > > > Additionally, > > > > > > > > > > we > > > > > > > > > > > > need > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > return a > > > > > > > > > > > > > > > > > > > > > > >> superset > > > > > > > > > > > > > > > > > > > > > > >> > of > > > > > > > > > > > > > > > > > > > > > > >> > > the ConfigResponse (an > > > > > Iceberg-core > > > > > > > > concept) > > > > > > > > > > > for > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > REST > > > > > > > > > > > > > > > > > > API > > > > > > > > > > > > > > > > > > > > > > >> response. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > Now, if the answer to #1 > is > > > yes, > > > > > > that > > > > > > > > means > > > > > > > > > > we > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > > > probably > > > > > > > > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > > > >> > > separate API for > > > configuration. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > What do y'all think? > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > Go community, > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > Adam > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > On Mon, Jun 22, 2026 at > > > 1:55 PM > > > > > > Yufei > > > > > > > > Gu < > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > I think a Polaris client > > is > > > > also > > > > > > an > > > > > > > > IRC > > > > > > > > > > > > client, > > > > > > > > > > > > > > just > > > > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > > > > > > additional > > > > > > > > > > > > > > > > > > > > > > >> > > > capabilities. In that > > sense, > > > > > > Polaris > > > > > > > > can > > > > > > > > > > be > > > > > > > > > > > > > viewed > > > > > > > > > > > > > > > as > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > superset > > > > > > > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > > > > > >> > IRC. > > > > > > > > > > > > > > > > > > > > > > >> > > If > > > > > > > > > > > > > > > > > > > > > > >> > > > the config endpoint is > > > > intended > > > > > > for > > > > > > > > > > > capability > > > > > > > > > > > > > > > > > discovery, > > > > > > > > > > > > > > > > > > > > > > returning > > > > > > > > > > > > > > > > > > > > > > >> > > Polaris > > > > > > > > > > > > > > > > > > > > > > >> > > > specific endpoints seems > > > > > > reasonable. > > > > > > > > > > > Standard > > > > > > > > > > > > > IRC > > > > > > > > > > > > > > > > > clients > > > > > > > > > > > > > > > > > > > can > > > > > > > > > > > > > > > > > > > > > > simply > > > > > > > > > > > > > > > > > > > > > > >> > > ignore > > > > > > > > > > > > > > > > > > > > > > >> > > > endpoints they don't > > > > recognize. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > A concrete example is > the > > > > > Polaris > > > > > > > > Spark > > > > > > > > > > > > client, > > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > > checks > > > > > > > > > > > > > > > > > > > > > > server > > > > > > > > > > > > > > > > > > > > > > >> > > > capabilities before > using > > > > > Polaris > > > > > > > > specific > > > > > > > > > > > > > > > > > functionality: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > public > > List<TableIdentifier> > > > > > > > > > > > > > > > > listGenericTables(Namespace > > > > > > > > > > > > > > > > > > > ns) { > > > > > > > > > > > > > > > > > > > > > > >> > > > > > Endpoint.check(endpoints, > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > PolarisEndpoints.V1_LIST_GENERIC_TABLES); > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > Yufei > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > On Fri, Jun 19, 2026 at > > > > 7:43 AM > > > > > > Dmitri > > > > > > > > > > > > > > Bourlatchkov > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > >> [email protected]> > > > > > > > > > > > > > > > > > > > > > > >> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > During my review of > > > [4816] I > > > > > > > > realized > > > > > > > > > > [1] > > > > > > > > > > > > that > > > > > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > > > > > > returns > > > > > > > > > > > > > > > > > > > > > > >> some > > > > > > > > > > > > > > > > > > > > > > >> > > > non-IRC > > > > > > > > > > > > > > > > > > > > > > >> > > > > endpoints in the IRC > > > config > > > > > > > > responses. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > For example: > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > GET ' > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > http://localhost:8181/api/catalog/v1/config?warehouse=polaris > > > > > > > > > > > > > > > > > ' > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > Result: > > > > > > > > > > > > > > > > > > > > > > >> > > > > [...] > > > > > > > > > > > > > > > > > > > > > > >> > > > > "endpoints": [ > > > > > > > > > > > > > > > > > > > > > > >> > > > > "GET > > > > > > /v1/{prefix}/namespaces", > > > > > > > > > > > > > > > > > > > > > > >> > > > > "GET > > > > > > > > > > > > /v1/{prefix}/namespaces/{namespace}", > > > > > > > > > > > > > > > > > > > > > > >> > > > > "HEAD > > > > > > > > > > > > > /v1/{prefix}/namespaces/{namespace}", > > > > > > > > > > > > > > > > > > > > > > >> > > > > [...] > > > > > > > > > > > > > > > > > > > > > > >> > > > > "DELETE > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris/v1/{prefix}/namespaces/{namespace}/generic-tables/{generic-table}", > > > > > > > > > > > > > > > > > > > > > > >> > > > > "GET > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris/v1/{prefix}/namespaces/{namespace}/generic-tables/{generic-table}", > > > > > > > > > > > > > > > > > > > > > > >> > > > > "GET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /polaris/v1/{prefix}/namespaces/{namespace}/policies", > > > > > > > > > > > > > > > > > > > > > > >> > > > > "POST > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /polaris/v1/{prefix}/namespaces/{namespace}/policies", > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > The latter group of > > > > endpoints > > > > > > is not > > > > > > > > > > > related > > > > > > > > > > > > > to > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > Iceberg > > > > > > > > > > > > > > > > > > > > > REST > > > > > > > > > > > > > > > > > > > > > > >> > > Catalog > > > > > > > > > > > > > > > > > > > > > > >> > > > > API. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > I wonder what the > > > rationale > > > > > > might > > > > > > > > be for > > > > > > > > > > > > > > returning > > > > > > > > > > > > > > > > > them > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > IRC > > > > > > > > > > > > > > > > > > > > > > >> > > config > > > > > > > > > > > > > > > > > > > > > > >> > > > > response. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > From my POV, returning > > > them > > > > in > > > > > > the > > > > > > > > IRC > > > > > > > > > > > > config > > > > > > > > > > > > > > > > response > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > > >> incorrect > > > > > > > > > > > > > > > > > > > > > > >> > > > because > > > > > > > > > > > > > > > > > > > > > > >> > > > > these endpoints form > > APIs > > > > that > > > > > > > > follow a > > > > > > > > > > > > > > different > > > > > > > > > > > > > > > > > > > > > specification > > > > > > > > > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > > > > > > > > > >> > > > clients > > > > > > > > > > > > > > > > > > > > > > >> > > > > using the IRC API do > not > > > > need > > > > > > that > > > > > > > > > > > > information > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > properly > > > > > > > > > > > > > > > > > > > > use > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > >> > IRC > > > > > > > > > > > > > > > > > > > > > > >> > > > API. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > WDYT? > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > [1] > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/4816#discussion_r3438945230 > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > [4816] > > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/4816 > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > >> > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Dmitri Bourlatchkov > > > > > > > > > > > > > > > Senior Staff Software Engineer, Dremio > > > > > > > > > > > > > > > Dremio.com > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / > > > > > > > > > > > > > > > Follow Us on LinkedIn < > > > > > > > > https://www.linkedin.com/company/dremio> > > > > > > > > > > / > > > > > > > > > > > > Get > > > > > > > > > > > > > > > Started <https://www.dremio.com/get-started/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Agentic Lakehouse > > > > > > > > > > > > > > > The only lakehouse built for agents, managed by > > > > agents > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
