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
