-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
Current Problem
Our current enum-based protocol approach has type safety issues:
enum StreamRequest {
GetStreamInfo,
RequestChunk { chunk_id: u64 },
}
enum StreamResponse {
StreamInfo { ... },
AudioChunk { ... },
}Issue: StreamRequest::GetStreamInfo could accidentally return StreamResponse::AudioChunk - compiler won't prevent this.
Proposed Solution: &'static str Protocols
// Protocol constants - clean and efficient
pub const AUDIO_GET_INFO: &'static str = "audio.get_info";
pub const AUDIO_REQUEST_CHUNK: &'static str = "audio.request_chunk";
// Separate request/response types for each protocol
struct AudioInfoRequest;
struct AudioInfoResponse { total_chunks: u64, ... }
struct AudioChunkRequest { chunk_id: u64 }
struct AudioChunkResponse { data: Vec<u8>, ... }Benefits
- Natural constraints: Low cardinality enforced - protocols must be hardcoded constants
- No runtime construction: Prevents dynamic protocol generation
- Type safety: Each protocol has dedicated request/response types
- Clean JSON: No enum variant names cluttering wire protocol
- Easy scaling: Clean namespacing (audio., video., screen.*)
Implementation
Update fastn_p2p::client::call() and fastn_p2p::listen().handle_requests() to accept &'static str instead of enum types.
Priority
Medium - current enum approach works but this would be much cleaner for complex applications with many protocols.
Metadata
Metadata
Assignees
Labels
No labels