Major changes: - Organized Python v1 implementation into v1/ subdirectory - Created Rust workspace with 9 modular crates: - wifi-densepose-core: Core types, traits, errors - wifi-densepose-signal: CSI processing, phase sanitization, FFT - wifi-densepose-nn: Neural network inference (ONNX/Candle/tch) - wifi-densepose-api: Axum-based REST/WebSocket API - wifi-densepose-db: SQLx database layer - wifi-densepose-config: Configuration management - wifi-densepose-hardware: Hardware abstraction - wifi-densepose-wasm: WebAssembly bindings - wifi-densepose-cli: Command-line interface Documentation: - ADR-001: Workspace structure - ADR-002: Signal processing library selection - ADR-003: Neural network inference strategy - DDD domain model with bounded contexts Testing: - 69 tests passing across all crates - Signal processing: 45 tests - Neural networks: 21 tests - Core: 3 doc tests Performance targets: - 10x faster CSI processing (~0.5ms vs ~5ms) - 5x lower memory usage (~100MB vs ~500MB) - WASM support for browser deployment
2.2 KiB
2.2 KiB
ADR-001: Rust Workspace Structure
Status
Accepted
Context
We need to port the WiFi-DensePose Python application to Rust for improved performance, memory safety, and cross-platform deployment including WASM. The architecture must be modular, maintainable, and support multiple deployment targets.
Decision
We will use a Cargo workspace with 9 modular crates:
wifi-densepose-rs/
├── Cargo.toml # Workspace root
├── crates/
│ ├── wifi-densepose-core/ # Core types, traits, errors
│ ├── wifi-densepose-signal/ # Signal processing (CSI, phase, FFT)
│ ├── wifi-densepose-nn/ # Neural networks (DensePose, translation)
│ ├── wifi-densepose-api/ # REST/WebSocket API (Axum)
│ ├── wifi-densepose-db/ # Database layer (SQLx)
│ ├── wifi-densepose-config/ # Configuration management
│ ├── wifi-densepose-hardware/ # Hardware abstraction
│ ├── wifi-densepose-wasm/ # WASM bindings
│ └── wifi-densepose-cli/ # CLI application
Crate Responsibilities
- wifi-densepose-core: Foundation types, traits, and error handling shared across all crates
- wifi-densepose-signal: CSI data processing, phase sanitization, FFT, feature extraction
- wifi-densepose-nn: Neural network inference using ONNX Runtime, Candle, or tch-rs
- wifi-densepose-api: HTTP/WebSocket server using Axum
- wifi-densepose-db: Database operations with SQLx
- wifi-densepose-config: Configuration loading and validation
- wifi-densepose-hardware: Router and hardware interfaces
- wifi-densepose-wasm: WebAssembly bindings for browser deployment
- wifi-densepose-cli: Command-line interface
Consequences
Positive
- Clear separation of concerns
- Independent crate versioning
- Parallel compilation
- Selective feature inclusion
- Easier testing and maintenance
- WASM target isolation
Negative
- More complex dependency management
- Initial setup overhead
- Cross-crate refactoring complexity