Hi Xuan, Thank you for the detailed response. This addresses the questions I raised and provides a clear picture of the client’s compatibility scope, provenance, dependencies, maintenance plan, and current API coverage.
>From my perspective as a PMC member, I do not see any obvious blocker to moving this proposal toward a formal vote. I suggest leaving this DISCUSS thread open for a short period so that other community and PMC members can provide feedback. If no major concerns are raised, I will start a separate [VOTE] thread to accept the code donation and create the apache/iotdb-client-rust repository. Thanks again for preparing all the requested information. Best regards, Haonan On 2026/07/15 07:31:35 王旋 wrote: > Hi, > > Thank you very much for the supportive and detailed reply. The suggested > route (code donation to the existing TLP + ASF IP clearance, rather than > incubation) makes sense to me, and I'm glad full Java-parity is not a > prerequisite — an incremental, roadmap-tracked approach matches how the > client was built. > > Below are the five items requested before a vote. > > ## 1. Supported IoTDB version matrix > > | IoTDB version | Status | Evidence | > |---|---|---| > | 2.0.6 | Supported | CI integration job runs the full live test suite + 3 > examples against apache/iotdb:2.0.6-standalone on every push | > | 2.0.10 | Supported | Full benchmark + data-correctness verification (all > 10 data types, tree & table, nulls) against a 2.0.10 standalone deployment | > | 2.0.x (general) | Expected to work | Thrift IDL is synced from > iotdb-protocol/ master; protocol version V3; no version-specific branching > in the client | > | 1.x | Not targeted | Table model and several data types > (TIMESTAMP/DATE/BLOB/STRING) assume 2.x; no plan to support 1.x | > > TLS was verified end-to-end against 2.0.6 with enable_thrift_ssl (TLSv1.3, > full certificate verification). RPC compression (compact protocol) verified > against a server with dn_rpc_thrift_compression_enable=true. > > ## 2. Contributors and provenance > > The entire git history has a single author — myself (Wang Xuan / CritasWang > <[email protected]>). I am an existing Apache IoTDB committer with an ICLA > already on file, and I hold full ownership of this work, so the provenance > chain is straightforward. Two categories of code in the repo: > > - Hand-written code: 100% original work, written for this project, > Apache-2.0 headers on every file. > - Generated code (src/protocol/): produced by the Apache Thrift compiler > from the Apache IoTDB project's own IDL files (iotdb-protocol/, ALv2); the > generation pipeline (tools/generate-thrift.sh) is documented and > reproducible. > > No code was copied from other client SDKs; the Java/C#/Node.js clients were > used as behavioral references only (wire-protocol semantics), which is also > how the cross-client protocol issues (e.g. the Node.js DATE encoding bug) > were found. > > ## 3. Dependency and license inventory > > Runtime dependencies (4 + 1 optional): > > | Crate | Version | License | Purpose | > |---|---|---|---| > | thrift | 0.23 | Apache-2.0 | RPC (matches the compiler version pinned by > the IoTDB pom) | > | byteorder | 1.5 | Unlicense OR MIT | Big-endian encoding | > | chrono | 0.4 | MIT OR Apache-2.0 | DATE handling | > | log | 0.4 | MIT OR Apache-2.0 | Logging facade | > | native-tls (optional, feature "tls") | 0.2 | MIT OR Apache-2.0 | TLS | > > Dev-dependency: env_logger (MIT OR Apache-2.0). Full transitive closure: 74 > packages, machine-checked — every one is MIT / Apache-2.0 / Unlicense / BSD > / Zlib dual-or-multi licensed, i.e. 100% ASF Category-A. Zero Category-B/X, > zero unknown-license packages. The full inventory (cargo metadata) can be > attached to the IP-clearance checklist. > > ## 4. Proposed initial maintainers and maintenance plan > > - Initial maintainer: myself (CritasWang — existing IoTDB committer). I > commit to maintaining the client — issue triage, protocol-sync with > iotdb-protocol changes, and regular releases through the normal IoTDB > community process — and to growing co-maintainers from the community; > review bandwidth from other committers/PMC members on client-facing changes > would be welcome. > - The repo already carries the practices expected for handover: CI (fmt / > clippy -D warnings / license check / unit tests / live integration against > a service container), bilingual READMEs, runnable examples, a > statistics-aligned benchmark, and a documented codegen pipeline. Nothing > depends on my personal infrastructure. > > ## 5. API support matrix (vs Java client) and near-term roadmap > > Supported today (feature → Java-client equivalent): > > | Area | Rust today | Java client | > |---|---|---| > | Session lifecycle, multi-node URLs, failover, auto-reconnect | ✅ | ✅ | > | insertTablet / insertTablets | ✅ | ✅ | > | insertRecord(s) / insertRecordsOfOneDevice (+ aligned variants) | ✅ | ✅ | > | Table model (TableSession/Pool, TAG/FIELD/ATTRIBUTE) | ✅ | ✅ | > | SessionPool / TableSessionPool (idle eviction, redirection cache) | ✅ | ✅ > | > | Query + paging iteration (TsBlock, fetchResultsV2) | ✅ | ✅ | > | All data types incl. TIMESTAMP/DATE/BLOB/STRING | ✅ | ✅ | > | TLS (incl. client identity) / RPC compression | ✅ | ✅ | > | deleteData / deleteTimeseries / DDL helpers | SQL only | ✅ dedicated APIs > | > | Schema templates | ❌ | ✅ | > | executeRawDataQuery / executeLastDataQuery / aggregation APIs | ❌ | ✅ | > | Per-type encoding tuning (RPC compression V2) | ❌ | ✅ | > > Near-term roadmap (order negotiable with the community): > > 1. async (tokio) API layer — most-requested Rust-ecosystem feature, kept > out of v0.1 to keep the sync core small > 2. crates.io releases under the Apache project > > I'll keep this thread open for feedback on maintenance ownership and API > scope as suggested. Since I'm an existing committer with an ICLA on file > and the sole author, the IP-clearance paperwork should be light — I'm happy > to prepare whatever the PMC deems necessary (software grant if required for > the pre-existing external history, plus the dependency inventory above) > whenever the community feels ready to move to a VOTE. > > Best regards, > Xuan Wang > > Haonan Hou <[email protected]> 于2026年7月15日周三 15:06写道： > > > Hi Xuan, > > > > Thank you for sharing this work. The implementation already covers a > > substantial part of the client functionality, and the test coverage, live > > integration testing, CI setup, and benchmark results are all encouraging. > > > > The protocol issues and performance improvements discovered while > > validating > > against the other clients are also a good indication that this work can > > benefit the broader IoTDB client ecosystem. > > > > As a member of the IoTDB PMC, I support bringing a well-maintained Rust > > client > > into the Apache IoTDB project. Based on what you have presented, I believe > > this > > repository is a strong candidate for donation and for becoming an official > > IoTDB client. > > > > Since IoTDB is already an Apache top-level project, the appropriate route > > should be a code donation to the existing project, followed by the ASF IP > > clearance process, rather than incubation as a separate project. > > > > I suggest the following next steps: > > > > 1. Continue this DISCUSS thread to collect feedback from the community, > > especially regarding maintenance ownership and the initial API scope. > > 2. Prepare a concise compatibility and API-support matrix against the Java > > client, together with a near-term roadmap. > > 3. If there are no major concerns, start a formal PMC VOTE to accept the > > code > > donation and create the apache/iotdb-client-rust repository. > > 4. Complete the software grant, code provenance, dependency/license review, > > and ASF IP clearance. > > 5. Move the code to the Apache repository and continue development and > > releases through the normal IoTDB community process. > > > > I do not think complete Java client API parity needs to be a prerequisite > > for > > the donation. The current functionality appears sufficient to establish a > > useful official client. APIs such as schema-template operations and > > additional > > session-level query methods can be added incrementally and tracked through > > a > > public roadmap. > > > > Before moving to a vote, it would be helpful to provide: > > > > - The supported IoTDB version matrix. > > - A list of contributors and confirmation of the code’s > > ownership/provenance. > > - A dependency and license inventory. > > - The proposed initial maintainers and long-term maintenance plan. > > - An API support matrix and near-term roadmap. > > > > Overall, I am supportive of this proposal and am willing to help move the > > discussion and donation process forward. > > > > Best regards, > > Haonan Hou > > > > On 2026/07/15 03:50:24 王旋 wrote: > > > Hi all, > > > > > > I'd like to share a Rust client SDK for Apache IoTDB that I've been > > > developing, and ask for the community's feedback on whether there is > > > interest in bringing it into the Apache IoTDB ecosystem. > > > > > > Repository: https://github.com/CritasWang/iotdb-client-rust > > > > > > Scope & features > > > > > > Tree model (Session) and table model (TableSession / SQL dialect), > > > mirroring the API shape of the Java / C# / Node.js clients > > > Write APIs: insertTablet / insertTablets (multi-tablet batching), > > > insertRecord(s), insertRecordsOfOneDevice, plus aligned variants > > > SessionPool and TableSessionPool: RAII checkout, lazy growth, idle > > > eviction, dead-connection eviction, write-redirection cache (status 400 > > > redirect hints), automatic reconnect with endpoint failover > > > Full data-type coverage including TIMESTAMP / DATE / BLOB / STRING; > > TsBlock > > > decoding with logical-type re-tagging (the TsBlock header carries > > physical > > > types — DATE arrives as INT32, BLOB as TEXT) > > > TLS (feature-gated, incl. client identity) — verified end-to-end against > > a > > > real IoTDB with enable_thrift_ssl; RPC compression (compact protocol) > > > Thrift codegen pipeline sources the IDL from iotdb-protocol/ and uses the > > > thrift compiler fetched by the IoTDB Maven build, so the stubs stay in > > > lockstep with the server > > > > > > Quality > > > > > > 113 unit tests (124 with TLS) + live integration tests that skip > > gracefully > > > without a server; CI on GitHub Actions runs fmt / clippy -D warnings / > > > license checks plus an integration job against an IoTDB 2.0.6 service > > > container — green > > > Statistics-aligned benchmark (measurement semantics mirror iot-benchmark: > > > prep inside the timed span, failures excluded from latency, > > Result/Latency > > > Matrix output). On a 16-core server writing 2B points per run (table > > model, > > > 100 devices x 20 DOUBLE sensors, 1000-row tablets, 20 sessions), the Rust > > > client sustains ~46-47M points/s — statistically tied with > > iot-benchmark's > > > Java Session path on the same box, where the server, not the client, is > > the > > > ceiling > > > Every file carries the ASF Apache 2.0 header > > > > > > Side effects the community already received > > > > > > Cross-validating the wire protocol against the Java / C# / Node.js > > > implementations surfaced two upstream issues in the Node.js client, both > > > now addressed: the DATE wire-encoding fix (apache/iotdb-client-nodejs#14, > > > PR #15, merged) and a write-path serialization optimization (+52% > > > throughput, PR #16, under review). > > > > > > Questions for the community > > > > > > Is there interest in an official Rust client under the Apache IoTDB > > > umbrella (e.g., apache/iotdb-client-rust), following the path of the > > > Node.js / C# clients? > > > If so, what would the preferred route be — code donation via the > > incubator > > > process for client SDKs, or starting a repo under the existing project > > and > > > iterating there? > > > Any API-surface expectations from the PMC side before such a move (e.g., > > > schema-template APIs, session-level query APIs like executeRawDataQuery)? > > > I'm happy to keep maintaining it either way, and to align the roadmap > > with > > > the community's priorities. > > > > > > 大家好 > > > > > > 我想向社区分享一个我一直在开发的 Apache IoTDB Rust 客户端 SDK，并征求大家的意见：社区是否有兴趣将它纳入 Apache > > > IoTDB 生态。 > > > > > > 仓库地址：https://github.com/CritasWang/iotdb-client-rust > > > > > > 范围与功能 > > > > > > 树模型（Session）与表模型（TableSession / SQL 方言），API 形态与 Java / C# / Node.js 客户端对齐 > > > 写入 API：insertTablet / insertTablets（多 tablet > > > 批量）、insertRecord(s)、insertRecordsOfOneDevice，以及 aligned 变体 > > > SessionPool 与 TableSessionPool：RAII 借还、惰性增长、空闲回收、死连接剔除、写重定向缓存（status 400 > > > 重定向提示）、带端点故障转移的自动重连 > > > 完整数据类型覆盖，包括 TIMESTAMP / DATE / BLOB / STRING；TsBlock 解码带逻辑类型重标记（TsBlock > > > 头携带的是物理类型——DATE 以 INT32 到达、BLOB 以 TEXT 到达） > > > TLS（feature 门控，含客户端证书）——已对开启 enable_thrift_ssl 的真实 IoTDB 完成端到端验证；RPC > > > 压缩（compact 协议） > > > Thrift 代码生成流水线：IDL 取自 iotdb-protocol/，编译器使用 IoTDB Maven 构建拉取的版本，确保 stub > > > 与服务端严格同步 > > > > > > 质量 > > > > > > 113 个单元测试（含 TLS 为 124 个）+ 无服务器时优雅跳过的 live 集成测试；GitHub Actions CI 运行 fmt / > > > clippy -D warnings / license 检查，另有针对 IoTDB 2.0.6 service container 的集成 > > > job——全绿 > > > 统计口径对齐的基准测试（测量语义对齐 iot-benchmark：批准备计入计时段、失败不计入延迟、Result/Latency Matrix > > > 输出）。在 16 核服务器上每轮写入 20 亿点（表模型、100 设备 x 20 个 DOUBLE 测点、1000 行/tablet、20 > > > 会话），Rust 客户端持续吞吐约 4600-4700 万点/秒——与同机 iot-benchmark 的 Java Session > > > 路径统计学持平，此时瓶颈在服务端而非客户端 > > > 所有文件均带 ASF Apache 2.0 头 > > > > > > 社区已经收到的副产品 > > > > > > 在与 Java / C# / Node.js 实现交叉验证线上协议的过程中，发现了 Node.js 客户端的两个上游问题，目前均已处理：DATE > > > 线上编码修复（apache/iotdb-client-nodejs#14，PR #15，已合并）以及写路径序列化优化（吞吐 +52%，PR > > > #16，评审中）。 > > > > > > 想请教社区的问题 > > > > > > 社区是否有兴趣在 Apache IoTDB 旗下提供官方 Rust 客户端（例如 apache/iotdb-client-rust），沿用 > > > Node.js / C# 客户端的路径？ > > > 如果有，倾向的路线是什么——通过客户端 SDK 的代码捐赠流程，还是先在现有项目下建仓库迭代？ > > > 在此之前，PMC 对 API 面是否有预期要求（例如 schema 模板 API、executeRawDataQuery 等会话级查询 API）？ > > > 无论结果如何，我都会继续维护它，并愿意将路线图与社区的优先级对齐。 > > > > > > Best regards, > > > Xuan Wang > > > > > >
