NuttX doesn't have a SSH Client/Server support yet.

Supporting a SSH server will open doors to let NuttX boards in the fields to be access remotely for maintenance

Adding support to SSH client will let low cost boards powered by NuttX and LVGL to become a remote console control for more advanced Linux server. 

Background

Apache IoTDB (Internet of Things Database) is a high-performance, open-source time-series database optimized for data management and analysis in IoT scenarios. Trino (formerly PrestoSQL) is a fast distributed SQL query engine designed for running interactive analytic queries against data sources of all sizes.
Currently, while IoTDB provides strong capabilities for writing and querying time-series data, integrating it with the broader big data ecosystem for complex OLAP (Online Analytical Processing) remains a demand. A dedicated Trino connector for IoTDB will allow users to query IoTDB data using standard SQL via Trino and perform federated queries with other data sources (like Hive, MySQL, or Iceberg).

Goal

The goal of this project is to implement a trino-iotdb connector plugin based on the Trino SPI (Service Provider Interface). This connector will enable Trino to read data directly from IoTDB, supporting schema mapping, data projection, and predicate pushdown or maybe aggregate pushdown.
 

Core Tasks（Mandatory）

1. Project Scaffolding: Set up the Maven project structure for the trino-iotdb plugin and integrate the IoTDB JDBC API.

2. Metadata Implementation: Implement ConnectorMetadata to map IoTDB’s Table Mode (relational view) to Trino’s relational metadata model:

   1. 
      Map IoTDB databases to Trino Schemas.
   2. 
      Map IoTDB Tables to Trino Tables.
   3. 
      Map IoTDB Data Type to Trino Data Type.

3. Column Pruning (Projection Pushdown): Ensure the connector strictly fetches only the requested columns (measurements) from IoTDB, avoiding SELECT * overhead.

4. Predicate Pushdown: Implement optimization rules to push down SQL filters (especially time range filters and value filters) to the IoTDB engine to minimize data transfer.

5. Limit & Offset Pushdown: Map Trino’s LIMIT and OFFSET clauses to IoTDB’s native query pagination to prevent fetching excessive data during preview or pagination queries.

6. Integration Testing: Provide Docker-based integration tests to verify correctness using Trino's testing framework.

Advanced Tasks (Optional)

• Aggregation Pushdown: Implement the applyAggregation method in the connector SPI.

  • 
    Goal: Map Trino’s aggregate functions (e.g., COUNT, AVG, SUM, MIN, MAX) directly to IoTDB’s native aggregation queries.
  • 
    Benefit: Instead of fetching raw data to Trino for calculation, the connector leverages IoTDB's pre-calculated statistics or downsampling capabilities, significantly reducing network overhead and latency.

Deliverables

• 
  A fully functional trino-iotdb connector source code.(a pull request to Trino Repo)
• 
  Comprehensive integration tests covering data types and query patterns.
• 
  User documentation explaining how to configure and use the connector.

Recommended Skills

• Java: Proficiency in Java programming (Trino and IoTDB are both Java-based).

• Database Internals: Basic understanding of SQL execution, schema design, and database connectors.

• Maven: Experience with Java build systems.

• Nice to have: Familiarity with Trino SPI or IoTDB Session API.

Learning Material

• 
  Apache IoTDB: https://iotdb.apache.org/
• 
  Trino Connector Developer Guide: https://trino.io/docs/current/develop/connectors.html
• 
  Trino PG Plugin: https://github.com/trinodb/trino/tree/master/plugin/trino-postgresql/src/main/java/io/trino/plugin/postgresql
• 
  IoTDB Java JDBC API: https://iotdb.apache.org/UserGuide/latest/API/Programming-JDBC_apache.html
• 
  IoTDB Table Model Concepts: https://iotdb.apache.org/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.html
• 
  IoTDB Table Model Query Syntax: https://iotdb.apache.org/UserGuide/latest-Table/SQL-Manual/overview_apache.html

 
Difficulty: medium
Mentor: Yuan Tian (Apache IoTDB PMC Member) (jackietien@apache.org)
 

Description

Currently, the HugeGraph core query engine is built on Java 11 + TinkerPop 3.5.x + Groovy 3. While this stack provides fundamental graph query capabilities, it lags behind in security, performance optimization, and support for modern features. Specifically, the built-in Groovy engine relies on complex, high-maintenance black/whitelist mechanisms for script security, which poses potential bypass risks.

The goal of this task is to comprehensively upgrade HugeGraph's underlying dependencies to Java 17 + TinkerPop 3.7/3.8 + Groovy 4. This is not just a version iteration, but a modern architectural transformation:

1. Groovy 4 & TinkerPop 3.7/3.8: Introduce improved syntax features and security designs. We aim to refactor HugeGraphSecurity using native, efficient sandboxing mechanisms to replace the legacy blacklist logic.
2. Java 17/21 Support: Adapt to the new JDK to fully leverage features like ZGC/Shenandoah GC, Records, and Virtual Threads, significantly improving throughput and reducing long-tail latency in large-scale graph queries.

Applicants are expected to handle the full lifecycle, from dependency upgrades and code refactoring to unit test fixes and final performance benchmarking.

Recommended Skills

1. Java Core: Proficiency in Java development with a solid understanding of Java 17+ new features.
2. HugeGraph Architecture: Basic understanding of HugeGraph's storage structure (KV Store), Schema design, and specifically the Gremlin query execution flow.
3. Graph Computing & Compilers: Familiarity with the TinkerPop Gremlin framework architecture; knowledge of AST (Abstract Syntax Tree) parsing or Functional Programming (FP) mindset is a plus.
4. AI Coding: Proficiency in using AI Coding tools (e.g., Codex, Claude Code, Copilot) to assist in code refactoring, test case optimization, and source code interpretation is highly preferred.
5. Security Awareness: Awareness of code security, understanding of how to prevent Script Injection, and experience designing secure sandbox environments.

💡 Important Notes for Applicants

1. Authenticity Matters: While we encourage the use of AI for coding efficiency, please strictly control and reasonably limit the use of LLMs when writing your project proposal/emails. We value genuine communication and mutual respect.
2. Proactive Engagement: We highly recommend participating in community Mini Tasks early. Demonstrating your hands-on ability within the community will significantly increase your chances of selection and help build trust with mentors.

Task List

• Dependency Analysis & Upgrade:
  • Analyze Breaking Changes from TinkerPop 3.5 to 3.7/3.8.
  • Complete core dependency version upgrades and API adaptations following mentor confirmation.

• Java 17 Environment Adaptation:
  • Resolve compile-time and runtime compatibility issues (e.g., reflection restrictions, module access) to ensure the Server module runs correctly on Java 17 (Java 21 is even better).
  • Update Docker configurations to migrate the default runtime to Java 17 (while exploring backward compatibility with Java 11).

• PD & Store Module Upgrade (New):
  • Extend the upgrade scope to the PD (Placement Driver) and Store modules after completing the core Server upgrade.
  • Ensure these modules are adapted to Java 17 to unify the runtime environment across the HugeGraph ecosystem.

• Security Module Refactoring:
  • Refactor the HugeGraphSecurity component based on Groovy 4 features.
  • Design a lightweight, secure script execution strategy and remove the performance-heavy legacy blacklist logic.

• Testing & Fixes:
  • Fix Unit Test (UT) failures caused by the upgrade.
  • Ensure all core functions (CRUD, complex Gremlin queries) pass verification.

• Performance Benchmarking:
  • Produce a performance comparison report: Java 11 (Old) vs. Java 17 (New) using the Twitter-14B public dataset.
  • Quantify improvements in Latency reduction and Throughput increases.

References

• New Contributor Guide: HugeGraph Contribution Guide (Issue #2212) - Environment setup & basics.

• Upgrade Docs: TinkerPop Upgrade Documentation

• Reference Implementation: JanusGraph Upgrade PR (For reference only)

• Gremlin Learning: Practical Gremlin Guide

• Project Wiki: HugeGraph Deepwiki

Project Size

• Difficulty: Medium (Similar references available)

• Estimated Time: ~250 Hours (~15 Weeks)

Mentors

• Yan Zhang: vaughn@apache.org (Apache HugeGraph PMC)

• Imba Jin: jin@apache.org (Apache HugeGraph PMC)

Description:
Apache Fory can generate high-performance Python model code from IDL, but Python gRPC stubs are not generated yet.
This project will implement Python gRPC integration in the Fory compiler by generating *_service.py and *_grpc.py
artifacts, using Fory serialization only (without protobuf runtime payload types).
The implementation should align with Fory’s compiler conventions and keep runtime overhead low.
Potential Outcomes:

• Generate *_service.py base interfaces and *_grpc.py gRPC binding files from service definitions.
• Generate servicer base classes and stub classes using gRPC unary/stream APIs.
• Wire request/response serialization via generated Fory serializer/deserializer callables.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-copy cannot be applied.
• Add golden codegen tests for output file names and key signatures.
• Provide a runnable Python server/client example with generated stubs and Fory codec.
• Update compiler documentation for Python gRPC code generation usage and constraints.

Skills:
Python, gRPC (grpcio), compiler/code generation, serialization internals, testing, performance optimization.
Difficulty: Medium
Project size: 175 hours
Potential mentors: Chaokun Yang, Weipeng Wang

Source links:

• https://github.com/apache/fory/issues/3273
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/python
• https://fory.apache.org/docs/guide/python/

Description

Apache Fory can already generate high-performance Java model code from IDL, but Java gRPC stubs are not generated
yet.
This project will implement Java gRPC integration in the Fory compiler by generating *Service.java and *Grpc.java artifacts, using Fory serialization only (no protobuf runtime types for payload encoding).
compiler conventions, and avoid adding gRPC runtime dependencies into Fory core.

• Generate *Service.java interfaces and *Grpc.java binding classes from service definitions.
• Generate gRPC MethodDescriptors, server binders, and client stubs (including unary/streaming modes supported by
  IR).
• Implement generated Fory-based Marshaller logic for request/response types.
• Add golden codegen tests for output file names and key method signatures.
• Provide a runnable Java server/client example using generated stubs and Fory codec.
• Update compiler documentation for Java gRPC code generation usage and limits.

Skills
Java, gRPC Java, compiler/code generation, serialization internals, testing.

Difficulty:Medium
Project size:175 hours

Potential mentors: Chaokun Yang, Weipeng Wang

Source links:

• https://github.com/apache/fory/issues/3272
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/java
• https://fory.apache.org/docs/next/guide/java/

Description:
Apache Fory can generate high-performance C++ model code from IDL, but it does not yet generate C++ gRPC service
bindings.
This project will add C++ gRPC code generation to the Fory compiler. For each service definition, the compiler should
generate service.h (service API), service.grpc.h (gRPC declarations), and service.grpc.cc (gRPC implementations),
using a Fory codec instead of protobuf runtime payload types.
The implementation should follow Fory compiler conventions and prioritize low-overhead, performance-first behavior.

Potential Outcomes:

• Parse service IR and generate C++ gRPC outputs for unary and streaming methods.
• Generate service.h, service.grpc.h, and service.grpc.cc with clear separation between API abstractions and transport
  bindings.
• Generate abstract service interfaces and client stub classes compatible with gRPC C++.
• Implement Fory-based request/response serialization hooks for gRPC marshalling.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-
  copy cannot be applied.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable C++ server/client example using generated bindings and Fory codec.
• Update compiler documentation for C++ gRPC code generation usage and constraints.

Skills:
C++ 17, gRPC, compiler/code generation, serialization internals, testing, performance optimization.

Difficulty: Medium
Project size: 175 hours
Potential mentors: Chaokun Yang, Weipeng Wang

Source links: * https://github.com/apache/fory/issues/3276

• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/cpp
• https://fory.apache.org/docs/guide/cpp/

 
Description:
Apache Fory can generate high-performance Rust model code from IDL, but it does not yet generate Rust gRPC service bindings.
This project will add Rust gRPC code generation to the Fory compiler using tonic. For each service definition, the compiler should generate service.rs (service API traits/modules) and service_grpc.rs (tonic server/client transport
The implementation should follow Fory compiler conventions and prioritize low-overhead, allocation-conscious runtime behavior.

Potential Outcomes:

• Generate service.rs and service_grpc.rs from service definitions, with clear separation between API traits and
  transport bindings.
• Generate tonic-compatible async server/client wrappers.
• Implement a custom tonic codec backed by Fory serialization/deserialization.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-
  copy cannot be applied.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable Rust server/client example using tonic + generated Fory codec bindings.
• Update compiler documentation for Rust gRPC code generation usage and constraints.

Skills:
Rust, gRPC (tonic), compiler/code generation, serialization internals, async Rust, testing, performance optimization.
Difficulty: Medium
Project size: 175 hours
Potential mentors: Chaokun Yang, Weipeng Wang
Source links:

• https://github.com/apache/fory/issues/3275
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/rust
• https://fory.apache.org/docs/guide/rust/

Description:
Apache Fory can generate high-performance Go model code from IDL, but it does not yet generate Go gRPC service
This project will add Go gRPC code generation to the Fory compiler. For each service definition, the compiler should
generate *_service.go (service interfaces) and *_grpc.go (gRPC transport bindings), using a Fory codec instead of
The implementation should follow Fory compiler conventions and prioritize low-overhead, performance-first behavior.

Potential Outcomes:

• Parse service IR and generate Go gRPC outputs for unary and streaming methods.
• Generate ServiceDesc, server interfaces, and client wrappers compatible with grpc-go.
• Register and use a custom Fory codec through grpc.CallOption for request/response serialization.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-copy cannot be applied.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable Go server/client example using generated bindings and Fory codec.
• Update compiler documentation for Go gRPC code generation usage and constraints.

Skills:
Go, gRPC (grpc-go), compiler/code generation, serialization internals, testing, performance optimization.

Difficulty: Medium
Project size: 175 hours
Potential mentors: Chaokun Yang, Weipeng Wang

Source links:

• https://github.com/apache/fory/issues/3274
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/go
• https://fory.apache.org/docs/guide/go/

Description:
Apache Fory currently lacks JavaScript/TypeScript gRPC service binding generation.
The generated service interface and gRPC binding outputs should follow existing JS/TS generator naming and layout conventions, stay dependency-light in Fory runtime, and keep runtime overhead low.
Potential Outcomes:

• Generate JS/TS service interface and gRPC binding outputs from service definitions, aligned with existing generator
  layout conventions.
• Wire request/response payload handling through generated Fory serializer/deserializer functions.
  copy cannot be applied.
• Coordinate with JS/TS type generation so emitted message/enum/union types are directly usable by generated gRPC
  stubs.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable JS/TS server-client example using generated bindings and Fory codec.
• Update compiler documentation for JS/TS gRPC code generation usage and constraints.

Skills:
JavaScript/TypeScript, Node.js, gRPC (@grpc/grpc-js), compiler/code generation, serialization internals, testing, performance optimization.

Difficulty: Medium
Project size: 175 hours
Potential mentors: Chaokun Yang, Weipeng Wang

Source links:

• https://github.com/apache/fory/issues/3278
  https://github.com/apache/fory/issues/3280
  https://fory.apache.org/docs/next/compiler/compiler_guide
  https://github.com/apache/fory/tree/main/compiler
  https://github.com/apache/fory/tree/main/javascript

Description

Apache Fory does not yet generate Dart gRPC service bindings.

This project will add Dart gRPC code generation to the Fory compiler. For each service definition, the compiler should generate Dart service interfaces and gRPC transport bindings that follow the existing Dart generator layout and use a Fory codec instead of protobuf runtime payload types.

The implementation must keep the Fory runtime free of gRPC dependencies. Any required gRPC glue should be emitted as generated helper code. Runtime behavior should remain low-overhead and allocation-conscious.

Potential Outcomes

• Generate Dart service interface and gRPC binding outputs from service definitions, aligned with current Dart generator conventions.
• Generate Dart gRPC server and client stubs for unary and streaming RPCs using Dart gRPC APIs.
• Wire request/response handling through generated Fory serializer and deserializer functions.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-copy cannot be applied.
• Coordinate with Dart type generation so emitted message, enum, and union types are directly usable by generated gRPC stubs.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable Dart server/client example using generated bindings and the Fory codec.
• Update compiler documentation for Dart gRPC code generation usage and constraints.

Skills：Dart, gRPC (`grpc`), compiler/code generation, serialization internals, async programming, testing, performance optimization.

Difficulty： Medium
Project size：175 hours
Potential mentors：Chaokun Yang, Weipeng Wang
Source links：

• https://github.com/apache/fory/issues/3279
• https://github.com/apache/fory/issues/3281
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/dart
• https://github.com/apache/fory/blob/main/dart/README.md
• https://github.com/apache/fory/tree/main/dart/packages/fory