Implement Bidirectional Connector Trait Enhancement
Summary
Extend the Connector trait to support bidirectional data flow, enabling connectors to both publish data (outbound) and subscribe to external data sources (inbound). This unblocks multiple connector implementations including KNX, MQTT subscribe, Kafka consumers, and WebSocket.
Full Design: See 012-M5-bidirectional-connector-trait.md
Motivation
Currently, connectors only support outbound data flow (AimDB → External System). Many protocols require inbound support:
- KNX: Listen to building automation bus telegrams
- MQTT: Subscribe to broker topics
- Kafka: Consume from topics
- WebSocket: Receive messages
This enhancement enables AimDB to act as both producer and consumer in IoT/edge architectures.
Key Design Decisions
✅ Stream Trait: Use futures-core::Stream (minimal, standard, no_std compatible)
✅ Embassy Support: Implement ChannelStream adapter (~30 lines) for unified API
✅ Breaking Change: Replace .link() with .link_from() / .link_to() for clarity
✅ Backward Compat: None needed (pre-1.0 project)
Implementation Tasks
Phase 1: Core Infrastructure (Week 1)
Phase 2: Builder API (Week 1-2)
Phase 3: Task Spawning (Week 2)
Phase 4: MQTT Validation (Week 2-3)
Phase 5: Documentation (Week 3)
Success Criteria
- ✅ MQTT connector supports both publish and subscribe
- ✅ Same
Connector trait works on Tokio and Embassy
- ✅ All tests pass (unit, integration, end-to-end)
- ✅ Documentation complete with examples
- ✅ Examples updated to use
.link_to() / .link_from()
Timeline
Target: 2-3 weeks
Priority: P0 (blocking KNX, MQTT subscribe, Kafka)
Related
Implement Bidirectional Connector Trait Enhancement
Summary
Extend the
Connectortrait to support bidirectional data flow, enabling connectors to both publish data (outbound) and subscribe to external data sources (inbound). This unblocks multiple connector implementations including KNX, MQTT subscribe, Kafka consumers, and WebSocket.Full Design: See 012-M5-bidirectional-connector-trait.md
Motivation
Currently, connectors only support outbound data flow (AimDB → External System). Many protocols require inbound support:
This enhancement enables AimDB to act as both producer and consumer in IoT/edge architectures.
Key Design Decisions
✅ Stream Trait: Use
futures-core::Stream(minimal, standard, no_std compatible)✅ Embassy Support: Implement
ChannelStreamadapter (~30 lines) for unified API✅ Breaking Change: Replace
.link()with.link_from()/.link_to()for clarity✅ Backward Compat: None needed (pre-1.0 project)
Implementation Tasks
Phase 1: Core Infrastructure (Week 1)
futures-coredependency toaimdb-coreConnector::subscribe()method with default empty stream implementationInboundConnectorLinkstruct for type erasureChannelStreamadapter inaimdb-embassy-adapter/src/stream.rsPhase 2: Builder API (Week 1-2)
.link()method fromRecordRegistrar.link_from()→InboundConnectorBuilder.link_to()→OutboundConnectorBuilderPhase 3: Task Spawning (Week 2)
AimDb::producer<T>()methodTokioAdapter::spawn_connector_tasks()for inboundEmbassyAdapter::spawn_connector_tasks()withChannelStreamPhase 4: MQTT Validation (Week 2-3)
subscribe()in Tokio MQTT connectorsubscribe()in Embassy MQTT connectorPhase 5: Documentation (Week 3)
ChannelStreamusage).link()→.link_to())Success Criteria
Connectortrait works on Tokio and Embassy.link_to()/.link_from()Timeline
Target: 2-3 weeks
Priority: P0 (blocking KNX, MQTT subscribe, Kafka)
Related