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