Request: Connectors for Zenoh

[utkuaydn]

Hi all,

I was wondering if it is worthwhile to add support for Zenoh. Personally, I would like to see the support, and it also could be a nice opportunity to get some recognition from SDV since they are pretty invested in Zenoh. I can try to contribute in my spare time, but it would be nice to know if you guys are interested before I put in any effort. Let me know what you think :)

[pjfanning]

Any submission will be considered.

[pjfanning]

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