Hi all, Thanks everyone for the great feedback and the active discussion so far — it's been really helpful in shaping the proposal.
Following the design in FIP-49, I've put together a PoC [1], built on top of Giorgos's branch [2] — thanks Giorgos for getting this started. It's still a work in progress and mainly covers the REST write path. I've also updated FIP-49 based on this discussion. Given how the discussion has converged, I'd like to start the vote tomorrow. If anyone would like more time for a final review, just let me know. [1] https://github.com/beryllw/fluss/commits/fip-49-poc/ [2] https://github.com/gstamatakis95/fluss/tree/feat/FIP-49 Best regards, Junbo Wang > On 6 Aug 2026, at 17:27, Junbo Wang <[email protected]> wrote: > > Hi Leonard and David, > > Thanks for raising this point, David. FIP-49 will focus on native Fluss > writes and lightweight lookups. As for the backend, FIP-49 will keep it to a > simple, lightweight implementation on top of fluss-rust, which we can evolve > and refactor when we bring in the query path with FIP-32. > > And thanks, Leonard, for helping clarify the authorization contract boundary > — I'll update FIP-49 accordingly. > > > > Best regards, > Junbo Wang > >> On 6 Aug 2026, at 11:38, Leonard Xu <[email protected]> wrote: >> >> Hi Junbo and all, >> >> Thanks for the detailed proposal and the follow-up explanations. >> >> I like the overall direction of keeping native REST operations directly on >> top of fluss-rust, while separating them from the future SQL/DataFusion path. >> The existing discussion has also covered the major runtime concerns well. >> >> I have just one clarification about the authorization contract. >> >> In service mode, all requests reach Fluss as the gateway service account, so >> Fluss cannot enforce per-user ACLs. In user mode, per-user authorization >> depends on the future act-as capability. >> >> Could we clarify this boundary in the FIP, for example: >> >> - service mode is intended for trusted or single-identity deployments, and >> all authenticated Gateway users share the service account's permissions; >> - user mode provides per-user Fluss authorization and requires act-as support >> from the Fluss cluster. >> >> This would also make the compatibility statement more precise: service mode >> works with existing clusters, while user mode requires the corresponding >> server capability. >> >> Other details such as batch partition grouping, memory admission and exact >> serialization handling can be refined during the OpenAPI and implementation >> reviews. >> >> Overall, +1 on the proposal and thanks for driving this! >> >> Best, >> Leonard >
