Finding
ROADMAP.md reports 0 unchecked items and the repo is tagged v1.0.0 ("Milestone 10 complete, version-freeze policy lifted") — but the entire roadmap never once mentions "RC Client" as a planned deliverable (confirmed via full-document grep). Checked the actual source tree to confirm this isn't just a documentation gap:
grep -rln "pub struct.*Controller\|pub struct.*Client" src/*.rs → zero matches. There is no client-side type anywhere.src/udp.rs defines UdpRcServer (a real, production UDP transport for the server role) — no client-side UDP dialer/controller exists alongside it.src/mock.rs defines RcServer/Endpoint — the reference test double is also server-only.src/adapt.rs's adapt() function wraps an Arc<RcServer> — meaning this crate's RELAY Caller binding represents an RC Server (something that receives and answers requests), not an RC Client (something that dials out and issues requests to a remote server).
Why this matters
Compare to go-RCP (also just reached v1.0.0, same TC18 replacement effort): it built both a Controller interface (satisfied by a real udp.Controller production client type) and the RC Server side, and its own Adapt(c Controller) relay.Caller wraps the client role — the side that actually issues requests to a remote peripheral, which is what a RELAY consumer most likely wants when integrating RCP (controlling a remote zone controller/peripheral over the network). rust-RCP's adapt() can only be used to expose a locally-hosted server for testing/simulation purposes, not to actually talk to a real remote RC Server as a client.
This looks like a genuine planning gap from when ROADMAP.md was first authored (the TC18 spec itself says RC Client implementation is intentionally unspecified/OEM-defined, which may have led the roadmap to treat "RC Client" as out of scope rather than as this crate's own necessary deliverable) — not a deliberate, documented scope decision.
Suggested fix
Add a new milestone: a real, production RC Client / network controller (mirroring go-RCP's udp.Controller shape — dial a remote RC Server over UDP, send an ACF_ABB/ACF_GBB request, block for the matching response) implementing whatever narrow interface adapt() should be rebuilt to wrap instead of (or in addition to) RcServer. This is likely a substantial milestone, not a small patch — comparable in scope to the original RC Server build-out.
Filed while comparing rust-RCP and go-RCP as reference implementations for RELAY's own upcoming RCP canonical-type/binding rework (RELAY spec v1.14 §15.5/§15.7.5 currently describes the retired pre-TC18 protocol and needs updating against a real, complete TC18 implementation).
Finding
ROADMAP.mdreports 0 unchecked items and the repo is tagged v1.0.0 ("Milestone 10 complete, version-freeze policy lifted") — but the entire roadmap never once mentions "RC Client" as a planned deliverable (confirmed via full-document grep). Checked the actual source tree to confirm this isn't just a documentation gap:grep -rln "pub struct.*Controller\|pub struct.*Client" src/*.rs→ zero matches. There is no client-side type anywhere.src/udp.rsdefinesUdpRcServer(a real, production UDP transport for the server role) — no client-side UDP dialer/controller exists alongside it.src/mock.rsdefinesRcServer/Endpoint— the reference test double is also server-only.src/adapt.rs'sadapt()function wraps anArc<RcServer>— meaning this crate's RELAYCallerbinding represents an RC Server (something that receives and answers requests), not an RC Client (something that dials out and issues requests to a remote server).Why this matters
Compare to go-RCP (also just reached v1.0.0, same TC18 replacement effort): it built both a
Controllerinterface (satisfied by a realudp.Controllerproduction client type) and the RC Server side, and its ownAdapt(c Controller) relay.Callerwraps the client role — the side that actually issues requests to a remote peripheral, which is what a RELAY consumer most likely wants when integrating RCP (controlling a remote zone controller/peripheral over the network). rust-RCP'sadapt()can only be used to expose a locally-hosted server for testing/simulation purposes, not to actually talk to a real remote RC Server as a client.This looks like a genuine planning gap from when
ROADMAP.mdwas first authored (the TC18 spec itself says RC Client implementation is intentionally unspecified/OEM-defined, which may have led the roadmap to treat "RC Client" as out of scope rather than as this crate's own necessary deliverable) — not a deliberate, documented scope decision.Suggested fix
Add a new milestone: a real, production RC Client / network controller (mirroring go-RCP's
udp.Controllershape — dial a remote RC Server over UDP, send an ACF_ABB/ACF_GBB request, block for the matching response) implementing whatever narrow interfaceadapt()should be rebuilt to wrap instead of (or in addition to)RcServer. This is likely a substantial milestone, not a small patch — comparable in scope to the original RC Server build-out.Filed while comparing rust-RCP and go-RCP as reference implementations for RELAY's own upcoming RCP canonical-type/binding rework (RELAY spec v1.14 §15.5/§15.7.5 currently describes the retired pre-TC18 protocol and needs updating against a real, complete TC18 implementation).