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
