Hi all, Thanks everyone for participating in the vote.
I’m closing this vote now. I’ll post the result in a separate thread. Best regards, Junbo Wang > On 12 Aug 2026, at 11:05, Hongshun Wang <[email protected]> wrote: > > +1 (binding) > > Best, > Hongshun > > On Tue, Aug 11, 2026 at 7:44 PM Jim Hu <[email protected]> wrote: > >> Thanks Junbo for driving this FIP. +1, non binding >> >> Best, >> Jim >> >> Yang Guo <[email protected]> 于2026年8月11日周二 18:08写道： >> >>> +1, non bindings >>> >>> Regards, >>> Yang Guo >>> >>> On Tue, Aug 11, 2026 at 11:00 AM Anton Borisov <[email protected]> >>> wrote: >>> >>>> +1, bindings >>>> >>>> -- Anton >>>> >>>> вт, 11 авг. 2026 г. в 03:44, Jark Wu <[email protected]>: >>>>> >>>>> +1 (binding) >>>>> >>>>> Best, >>>>> Jark >>>>> >>>>> On Mon, 10 Aug 2026 at 21:42, Zhe Wang <[email protected]> >> wrote: >>>>>> >>>>>> Thanks for driving this FIP. >>>>>> +1 (non-binding) >>>>>> >>>>>> Best regards, >>>>>> Zhe Wang >>>>>> >>>>>> >>>>>> Leonard Xu <[email protected]> 于2026年8月10日周一 17:56写道： >>>>>> >>>>>>> Thanks Junbo for driving this FIP. >>>>>>> >>>>>>> +1 (binding). >>>>>>> >>>>>>> Best, >>>>>>> Leonard >>>>>>> >>>>>>>> 2026 8月 9 11:15 上午，Junbo Wang <[email protected]> 写道： >>>>>>>> >>>>>>>> Hi Jark and all, >>>>>>>> >>>>>>>> Thanks a lot for the careful review — all three points make >> sense >>>> to me, >>>>>>> and I’ve updated the FIP [1] to address them: the lookup paths >> are >>>>>>> simplified, the supported operations per table type are >> documented >>>> together >>>>>>> with the error behavior, and the Authorization header, including >>>> Bearer >>>>>>> tokens, is now covered in the authentication section. >>>>>>>> >>>>>>>> As these feel more like clarifications than changes to the >> design >>>> under >>>>>>> vote, I’d suggest keeping the current vote open, with the 72 >> hours >>>> counted >>>>>>> from this update. That said, if any of them turns out to need >> more >>>>>>> discussion, I'm happy to bring it back to the DISCUSS thread [2] >>> and >>>> start >>>>>>> a fresh vote afterwards. >>>>>>>> >>>>>>>> Looking forward to further feedback. >>>>>>>> >>>>>>>> [1] >>>>>>> >>>> >>> >> https://cwiki.apache.org/confluence/spaces/FLUSS/pages/444334561/FIP-49+Fluss+Gateway+REST+API >>>>>>>> [2] >>>> https://lists.apache.org/thread/s5yjysvoj8o6nxdj49m99hg8yn51tgjw >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Junbo Wang >>>>>>>> >>>>>>>>> On 9 Aug 2026, at 09:45, Junbo Wang <[email protected]> >>> wrote: >>>>>>>>> >>>>>>>>> Hi Keith, >>>>>>>>> >>>>>>>>> Thanks for the reminder. This should already be a separate >>> [VOTE] >>>>>>> thread [1] — the mail was sent as a new email rather than a reply >>> to >>>> the >>>>>>> [DISCUSS] thread [2], and >>>>>>>>> its In-Reply-To/References headers are empty on the archive. >>> Your >>>> mail >>>>>>> client may have grouped it under the discussion because of the >>>> similar >>>>>>> subject. >>>>>>>>> >>>>>>>>> Please let me know whether it still looks off on your side. >>>>>>>>> >>>>>>>>> [1] >>>> https://lists.apache.org/thread/t5jkcvo8b07oxjywbckotbsxl8fhcd76 >>>>>>>>> [2] >>>> https://lists.apache.org/thread/s5yjysvoj8o6nxdj49m99hg8yn51tgjw >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Junbo Wang >>>>>>>>> >>>>>>>>>> On 8 Aug 2026, at 19:06, Jark Wu <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> 1. Could we remove the extra "records" segment from the >> lookup >>>> paths? >>>>>>>>>> >>>>>>>>>> Point Lookup: >>>>>>>>>> POST >>>> /v1/clusters/{cluster}/databases/{database}/tables/{table}/lookup >>>>>>>>>> >>>>>>>>>> Prefix Lookup: >>>>>>>>>> POST >>>>>>> >>>> >> /v1/clusters/{cluster}/databases/{database}/tables/{table}/prefix-lookup >>>>>>>>>> >>>>>>>>>> 2. The /records write API does not explicitly define its >>>> supported >>>>>>>>>> operation types. My understanding is that Log tables support >>>> "append" >>>>>>>>>> only, while primary-key/KV tables support "upsert" and >>> "delete". >>>> Could >>>>>>>>>> we document this operation/table compatibility and the error >>>> behavior >>>>>>>>>> for unsupported combinations? >>>>>>>>>> >>>>>>>>>> 3. Could we explicitly support and document the HTTP >>>> Authorization >>>>>>>>>> header, especially Authorization: Bearer <token>? This is a >>>> common >>>>>>>>>> authentication mechanism for cloud services: Databricks >> Zerobus >>>> and >>>>>>>>>> Confluent REST Proxy use OAuth/OIDC bearer tokens, while >>> Alibaba >>>> Cloud >>>>>>>>>> OSS carries signed credentials in the Authorization header >>>> [1][2][3]. >>>>>>>>>> The Gateway can validate the credential, resolve it to a >>>> principal, >>>>>>>>>> and propagate that principal through the existing >>> identity/act-as >>>>>>>>>> mechanism. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>> >>> >>
