mirror of
https://github.com/rzuasti/oott.git
synced 2026-07-08 19:21:54 +02:00
rzuastiandClaude Opus 4.8
936e9ffe79
Introduce a new SSDP/UPnP network scanner alongside the existing ARP and mDNS scanners: - New scanner module under scanners/ssdp (finder, scanner, status) - Wire the scanner into the main scan loop - Add Ssdp variant to DeviceEventScanner - Add SsdpScanner settings with a configurable probe timeout - Expose /api/ssdp_scanner/status and wire it into OpenAPI generation - Add a lint.sh helper and point CLAUDE.md at it Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
59 lines
3.7 KiB
Markdown
59 lines
3.7 KiB
Markdown
# Project OOTT
|
|
|
|
OOTT is an easy to setup network monitoring and alert system aimed at notifying when new or unknown devices join a local area network.
|
|
|
|
It has two major components:
|
|
- A backend service that runs the monitoring and other processes and provides a REST API. This is built with [Rust](https://rust-lang.org/).
|
|
- A front-end that enables the user to configure the system and access the data it stores. This is built with [Flutter](https://flutter.dev/) - a front-end framework based on the [Dart](https://dart.dev/) language.
|
|
|
|
|
|
## Code style
|
|
|
|
For Rust code:
|
|
- Use the standard [Rust style guide](https://doc.rust-lang.org/style-guide/)
|
|
- Use `rustfmt` to format the code
|
|
|
|
For Flutter/Dart code:
|
|
- Use the standard [Dart style guide](https://dart.dev/effective-dart/style)
|
|
- Use `dart format --output show` to format the code
|
|
|
|
## Project commands
|
|
|
|
- `cd backend && ./build.sh` from the `backend/` folder - Build the backend
|
|
- `cd backend && ./run.sh` from the `backend/` folder - Run the backend
|
|
- `cd frontend && ./run.sh` from the `frontend/` folder - Run the front-end for the web
|
|
- `cd backend && ./run_tests.sh` - Run the backend tests
|
|
- `cd backend && ./lint.sh` - Run the clippy linter for Rust code
|
|
- `dart analyze` - Run the Dart linter
|
|
- `cd backend/data && ./update_mac_vendors --llm` - Update the MAC vendors list from the web and re-calculate the vedors -> device type list
|
|
|
|
## Architecture
|
|
|
|
### General
|
|
- All backend source code is under the `backend/` folder
|
|
- All front-end source code is under the `frontend/` folder
|
|
- All interactions between the front-end and the backend are via the backend REST API
|
|
|
|
### Backend
|
|
- System state and events are stored in a SQLite database (`oott.db` by default) which is accessed and managed exclusively by the backend via a data access layer (`db.rs` and files under the `backend/src/db/` folder)
|
|
- Database structure is handled through incremental migrations (stored under the `backend/database_migrations` folder). Each set of structural changes should be a new database migration file.
|
|
- The backend's entry point is `src/main.rs` which starts two threads using the [Tokyo](https://tokio.rs/) framework: one for the network scanning process and another one for the web server that exposes the API and hosts the Flutter app (front-end) assets when deployed in a live environment (ie not development)
|
|
|
|
### Front-end
|
|
- The front-end's entry point is `lib/main.dart`
|
|
- It uses the [Material 3](https://m3.material.io/develop/flutter) framework for Flutter
|
|
- The application needs to be responsive and adapt to a web experience in the desktop, tablets and phones
|
|
- The application is also available in iOS and Android as a native experience (via de App Store and Play store)
|
|
- Backend API access is implemented in the `utils/oott_api.dart` component
|
|
|
|
## Important notes
|
|
- NEVER add or commit .env files or files with secrets (passwords, API keys or similar information)
|
|
- Code must be as simple as possible, human readable and modularized
|
|
- ALWAYS write unit tests for new or modified backend components
|
|
- ALWAYS run all tests after making a new change and do not continue until all tests pass
|
|
- When adding a new API endpoint, ALWAYS wire it to the OpenAPI generation
|
|
- When adding a significant chunk of new code (either Rust or Dart), run the corresponding linter
|
|
- In the frontend, use the UISnackbars component to display messages to the user that do not require action on their part.
|
|
- In the frontend, always use colors from the selected theme. Never hard code colors any other way. If a color is needed and it's not covered semantically by the theme, suggest an addition to the theme extension implemented in the project.
|
|
- In the backend Rust code, avoid import aliases ("use ... as ...") unless necessary
|