~/cases/owly-newsAktiv
Owly News
Ein Rust-Core und zwei Oberflächen, mit optionaler KI rund um den Reader.
→Architektur
owly-core besitzt Domain-Verhalten, SQLite-Persistenz, Abruf-Orchestrierung, Events und die Zusammenfasser-Grenze. Tauri/Svelte und ratatui bleiben an den Rändern.
RSS / Atom
Abruf + Aktualisierung abrufen · deduplizieren · wiederholen
owly-core Domain · SQLite · Events
Zusammenfasser optionaler Provider
Tauri · ratatui zwei Oberflächen
- Feeds gelangen über Abruf und Aktualisierung in den gemeinsamen Rust-Core.
- SQLite, Suche und Events bleiben in owly-core.
- Tauri/Svelte- und ratatui-Frontends nutzen dasselbe Verhalten; Zusammenfassungen sind optional.
→Graceful Degradation
Die Provider-Gesundheit steuert Zusammenfassungen; nicht verfügbare Provider lassen Artikel erneut versuchbar, während Feeds nutzbar bleiben.
→Abwägungen
Ein gemeinsamer Core verhindert Verhaltensdrift, aber Frontend-Adapter müssen seine Grenzen erhalten.
→Entscheidungen & Trade-offs
| Entscheidung | Warum | Trade-off |
|---|---|---|
| Zusammenfassung hinter einem Trait | Der Feedreader bleibt nützlich, wenn ein LLM nicht verfügbar ist. | Ausstehende Arbeit und Wiederholungen brauchen expliziten Zustand. |
→Ergebnis
- Die Architektur dokumentiert begrenzte Abruf-Konkurrenz, SQLite WAL, typisierte Tauri-Events und eine reine TUI-Zustandsmaschine.
→Nachweise
- Geteiltes Verhalten
- Rust-Core
- Lokale Persistenz
- SQLite
- LLM-Grenze
- Optional
Desktop- und Terminal-Frontends
WAL und paralleler Zugriff
Feeds laufen ohne Zusammenfassung weiter
→Was ich heute anders machen würde
KI ist hier am nützlichsten als austauschbare Fähigkeit um einen verlässlichen Reader-Core.