Thanks Junbo, I think we're converging on a good direction. I agree with keeping FIP-49 focused so we can deliver the REST write path quickly, and I also agree that FIP-32 may be easier to review if we split it into smaller protocol-specific FIPs over time.
>From an architectural perspective, I think it would be useful if we align on a few high-level design principles first (as a suggestion): - FIP-49 should focus on the REST gateway MVP (writes/DDL, with any additional read functionality kept intentionally small if we decide to include it). - FIP-32 (and potential follow-up FIPs) should focus on the query architecture and multi-protocol support. - My understanding from the previous discussions is that DataFusion is primarily intended for the SQL/query path, while native Fluss operations continue to build on the fluss-rust foundation. I'm also not suggesting introducing a large backend abstraction up front, but I think both the REST and query paths should build on the same underlying Fluss integration rather than evolving into separate implementations over time (I could imagine a thin shared layer built on top of fluss-rust). That could allow the REST and future protocol implementations to share common infrastructure where it makes sense (e.g. connection management, metadata handling and future authentication/doAs support) without coupling all native Fluss operations to DataFusion. If we can agree on those architectural boundaries first, I think we can iterate on the individual protocol implementations much more independently. WDYT? We should really make it clear, as there is much opinion and thoughts currently in everybody's mind. I think a shared understanding can help to reduce unnecessary efforts. Am Sa., 1. Aug. 2026 um 03:28 Uhr schrieb Junbo Wang <[email protected]>: > Thanks Keith for reviving this, and David & George for the FIP. > > +1 on narrowing scope. > One point I'd like to check on Arrow Flight — my understanding is that the > Arrow Flight SQL protocol in the FIP-32 < > https://cwiki.apache.org/confluence/spaces/FLUSS/pages/406622520/FIP-32+Multiprotocol+Query+Gateway+for+Apache+Fluss> > is a Flight SQL endpoint, which needs a SQL engine on the server side and > thus depends on fluss-datafusion. If that's the case, since > fluss-datafusion isn't ready yet (discussed in the fluss-rust roadmap), > perhaps we could hold it off for 1.0 and narrow to just REST for the > initial release, then add Flight SQL once fluss-datafusion lands. Please > correct me if I'm misreading this.(My understanding is that plain Arrow > Flight as a data-transport layer isn't part of this FIP — happy to discuss > separately if there's demand.) > > Happy to pick up part of the implementation once the scope settles. > > > Best regards, > Junbo Wang > > > On 31 Jul 2026, at 18:02, Keith Lee <[email protected]> wrote: > > > > David, George > >
