Problem
The moq-native public API is flat — types like WebSocketListener, Client, Server, ClientConfig, ServerConfig all live at the crate root. This makes it hard to discover what's available, and the naming gets verbose to avoid collisions (e.g. WebSocketListener vs just Listener).
The configuration also uses struct fields + with_* methods inconsistently rather than a proper builder pattern.
Proposed changes
Feature-gated modules
Organize types behind modules that match their feature gates:
// Instead of:
moq_native::WebSocketListener
moq_native::ClientWebSocket
// Use:
moq_native::ws::Listener
moq_native::ws::ClientConfig
// Similarly:
moq_native::quic::Client // quinn/quiche/noq backends
moq_native::quic::Server
moq_native::tls::Client // raw TLS/TCP via qmux
moq_native::tls::Server
Each module would be gated behind its feature flag (websocket, quinn, quiche, noq, etc.).
Builder pattern
Use builders for configuration instead of public struct fields:
// Instead of:
let mut config = ClientConfig::default();
config.tls.disable_verify = Some(true);
config.version = vec!["moq-transport-16".parse()?];
let client = config.init()?;
// Use:
let client = Client::builder()
.tls_disable_verify(true)
.version("moq-transport-16")
.build()?;This would make the API more discoverable and allow us to evolve internals without breaking changes.
Re-exports for convenience
Keep common types re-exported at the crate root for ergonomics:
pub use client::Client;
pub use server::Server;
Notes
- This is a breaking change, so it should target the
dev branch.
- The current
clap derive integration for CLI args should be preserved.
🤖 Generated with Claude Code
Problem
The
moq-nativepublic API is flat — types likeWebSocketListener,Client,Server,ClientConfig,ServerConfigall live at the crate root. This makes it hard to discover what's available, and the naming gets verbose to avoid collisions (e.g.WebSocketListenervs justListener).The configuration also uses struct fields +
with_*methods inconsistently rather than a proper builder pattern.Proposed changes
Feature-gated modules
Organize types behind modules that match their feature gates:
Each module would be gated behind its feature flag (
websocket,quinn,quiche,noq, etc.).Builder pattern
Use builders for configuration instead of public struct fields:
This would make the API more discoverable and allow us to evolve internals without breaking changes.
Re-exports for convenience
Keep common types re-exported at the crate root for ergonomics:
Notes
devbranch.clapderive integration for CLI args should be preserved.🤖 Generated with Claude Code