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