pjfanning commented on issue #1076: URL: https://github.com/apache/pekko-connectors/issues/1076#issuecomment-4147927500
Copilot gave this assessment of the feasibility of implementing a Zenoh connector for Apache Pekko Connectors: --- ## Feasibility Assessment: Zenoh Connector for Pekko Connectors ### ✅ What Works in Favour **1. A JVM client library exists** The [`eclipse-zenoh/zenoh-java`](https://github.com/eclipse-zenoh/zenoh-java) library (`io.zenoh`) provides a solid JVM API for Zenoh with: - **Publisher/Subscriber** pattern (`session.declarePublisher`, `session.declareSubscriber`) — maps naturally to Pekko `Source`/`Sink`/`Flow` - **Queryable** (request/reply) — could map to a Pekko `Flow` - **Session lifecycle** (`Zenoh.open`, `session.close`) — aligns with how other connectors manage connections - Callback and handler-based APIs — both useful for integrating with Pekko's async push-based stream model **2. The model fits Pekko Connectors' pub/sub pattern** Looking at the existing connectors (MQTT, AMQP, JMS), Zenoh's pub/sub semantics are a very natural fit. The pattern would be: - `ZenohSource` — wraps a `Subscriber` as a reactive stream source - `ZenohSink` — wraps a `Publisher`/`put` as a reactive stream sink - Optionally a `ZenohFlow` for request/reply via Queryable **3. Active ecosystem & strategic relevance** Zenoh is gaining momentum, especially in the [Eclipse SDV (Software Defined Vehicle)](https://sdv.eclipse.org/) ecosystem. There's clear community interest (the issue was labelled "help wanted"), and this could position Pekko well in the IoT/edge computing space — adjacent to the existing MQTT connectors. --- ### ⚠️ Challenges / Risks **1. Native library dependency** `zenoh-java` is a Kotlin-based wrapper around a **Rust core** (`zenoh`) via JNI. It ships platform-specific native binaries. This is a **significant departure** from most current Pekko connectors, which are pure JVM. Key concerns: - Platform-specific artifacts (Linux x86_64, ARM, macOS, Windows) need to be resolved at runtime - Integration testing would require running on a supported platform with the native binary present — harder to test in CI - ASF release policy may have opinions about bundling non-Java native artifacts **2. License consideration** `zenoh-java` is dual-licensed under **EPL-2.0 OR Apache-2.0**. The Apache-2.0 option is compatible with ASF, but this would need to be verified carefully during any IP review for inclusion in an Apache project. **3. No existing Scala wrapper** There is no idiomatic Scala API for Zenoh today — the connector would have to wrap the Java/Kotlin API directly, similar to how the `mqtt` connector wraps Paho. This is fine but adds a bit of friction. **4. Maturity of `zenoh-java`** The library is still relatively young and pre-1.0 in some respects. API stability should be assessed before committing to building a connector on top of it. --- ### 📋 Summary | Factor | Assessment | |---|---| | JVM client library available | ✅ Yes (`zenoh-java`) | | Pub/sub model fits Pekko Streams | ✅ Very well | | Pure JVM | ❌ No — requires native Rust via JNI | | License compatibility (ASF) | ✅ Likely (Apache-2.0 option) | | CI/testing complexity | ⚠️ Moderate — native binary required | | Community interest | ✅ "help wanted" label, contributor volunteered | | Precedent in repo | ✅ MQTT, AMQP, JMS are comparable patterns | **Overall: Technically feasible, but the native dependency is the main hurdle.** The connector logic itself would be straightforward to write following the MQTT connector as a template. The bigger question for the Apache Pekko project maintainers is whether they're comfortable with a JNI/native-binary dependency in the release artifacts, and whether the ASF IP review process can accommodate the `eclipse-zenoh` provenance. A practical first step would be for the contributor to prototype the connector outside the main repo (e.g. in a standalone project) to validate the approach, then raise it on the Pekko dev mailing list before formally proposing it for inclusion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
