+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. > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >
