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