Files
alknet/docs/architecture/questions/015-call-protocol-client-and-adapter-contract.md
T
glm-5.2 b0cc0a01b7 docs(arch): unweld CallClient from QUIC — spawn_dispatch primary, connect convenience (ADR-017 Am. 2026-07-13)
Same fix as ADR-080 (ChannelClient) applied to the call crate. The
existing code already had the right structure — spawn_dispatch is not
feature-gated (transport-agnostic), connect is #[cfg(feature = "quinn")]
— but the docs inverted the framing: connect was 'primary,' spawn_dispatch
was 'lower-level.' That welding masked the call protocol's
transport-agnosticism (ADR-012 EventEnvelope; ADR-065 from_stream/from_bidi
accept any AsyncRead + AsyncWrite).

Changes:
- client-and-adapters.md: reframe spawn_dispatch as the transport-
  agnostic primary constructor (one-way door), connect as the QUIC
  convenience (two-way door, feature-gated on quinn). Mirror the
  from_connection / connect_quic pattern from ADR-080/channel-client.md.
  Fix all 'QUIC-backed' / 'over QUIC' / 'opens a QUIC connection' framing
  to be transport-agnostic. Fix from_call description, adapter location
  map, exchange-of-operations example, Constraints section.
- call-protocol.md: 'runs over QUIC bidirectional streams' → 'runs over
  any ordered, reliable bidirectional stream.' Fix stream model, stream
  lifecycle (connection drop / stream reset now list all transports,
  not just QUIC). Fix CallConnection.connection doc comment.
- operation-registry.md: FromCall provenance comment 'QUIC forwarding
  stub' → 'call-protocol forwarding stub.' Fix from_call description.
- call README.md: fix client-and-adapters.md description, fix design
  principle #11 framing.
- ADR-017: add Amendment (2026-07-13) documenting the spawn_dispatch /
  connect reframe, mirroring ADR-080's amendment.
- overview.md, architecture README: update ADR-017 and
  client-and-adapters.md table summaries.
- OQ-015, OQ-007: fix 'opens QUIC connections' / 'bidirectional QUIC
  streams' framing in resolution text.

No code changes — spawn_dispatch and connect already exist with the
right feature-gate structure. This is a documentation reframe.
2026-07-13 09:53:43 +00:00

1.4 KiB

OQ-15: Call Protocol Client and Adapter Contract

  • Origin: call-protocol.md, operation-registry.md, ADR-013
  • Status: resolved
  • Door type: One-way
  • Priority: high
  • Resolution: CallClient takes over transport connections (spawn_dispatch transport-agnostic primary, connect QUIC convenience — ADR-017 Am. 2026-07-13) and shares the dispatch loop with CallAdapter — both sides can send and receive call.requested once connected. Connection direction (who opened the connection) is independent of call direction (who calls whom). from_call adapter discovers remote operations via services/list + services/schema and registers them with forwarding handlers — same pattern as from_openapi and from_mcp. to_openapi and to_mcp project local operations to external protocols. Adapter contract trait (OperationAdapter) produces HandlerRegistration bundles. Cross-node call tree: abort cascade (ADR-016) propagates across node boundaries through from_call handlers. Credentials for connections come from capabilities (ADR-014). Adapter-registered operations are Internal by default (ADR-015). See ADR-017.
  • Cross-references: ADR-005, ADR-013, ADR-014, ADR-015, ADR-016, ADR-017, call-protocol.md, operation-registry.md