Reorganize moq-native API: feature-gated modules and builder pattern #1097
Description
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::ServerEach 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
devbranch. - The current
clapderive integration for CLI args should be preserved.
🤖 Generated with Claude Code