ddidderr
c313f7c9ae
NEXT_STEPS item 2 still described the old per-file unrar provider shape even though the current shared provider now performs one technical listing pass and one sequential unrar payload pass per archive. Update the roadmap so the next implementation slice starts at the remaining solid-archive policy work instead of chasing an already-replaced extraction loop. The item 3 wording now keeps the solid/non-solid archive fork explicit without suggesting the current provider still needs to be swapped merely to avoid per-file extraction. Test Plan: - git diff --check Refs: NEXT_STEPS.md item 2
70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
# Streamed Install Next Steps
|
||
|
||
I’d treat the prototype as proof of the hard part: “can we stream
|
||
archive-derived install bytes into `local/` without making the receiver a
|
||
source?” Yes. Next I’d harden the pieces that decide whether this is
|
||
product-ready.
|
||
|
||
1. **Done — Move from CLI-only to real app integration**
|
||
|
||
The GUI now has an explicit “Low disk install” action in the game detail
|
||
modal for remote-only games. The Tauri backend queues that path through
|
||
`stream_install_game`, injects the shared external `unrar` stream provider,
|
||
and hands fetched file details to `StreamInstallGame` instead of the normal
|
||
download command.
|
||
|
||
2. **Done — Replace per-file `unrar p` with a final archive provider**
|
||
|
||
The shared external `unrar` stream provider now runs `unrar lt` once for the
|
||
archive metadata and one sequential `unrar p` pass per archive for payload
|
||
bytes. It frames directories, file starts, file chunks, and file ends from
|
||
the technical listing, so CLI and GUI callers use one purpose-built provider
|
||
instead of a per-file extraction loop.
|
||
|
||
3. **Handle solid archives deliberately**
|
||
|
||
The provider exposes the RAR `solid` flag in `ArchiveBegin`; the remaining
|
||
work is to make that flag a tested policy decision instead of an incidental
|
||
stream attribute. Add archive inspection that decides:
|
||
|
||
- non-solid: current one-pass streaming is fine
|
||
- solid: prove and enforce one sequential archive pass only
|
||
|
||
This is the big architectural fork we discussed: keep non-solid and solid
|
||
archive handling explicit in the provider contract and scenario coverage.
|
||
|
||
4. **Decide the integrity model**
|
||
|
||
Current prototype verifies streamed bytes against RAR CRC32 from the
|
||
sender’s archive headers. That catches corruption and provider bugs. It does
|
||
not protect against a malicious peer lying. If you care about that, the next
|
||
step is catalog-side trusted hashes for archive or extracted files.
|
||
|
||
5. **Upgrade retry/resume semantics**
|
||
|
||
Right now, failed stream means failed operation and rollback. Next useful
|
||
step:
|
||
|
||
- retry whole stream from another trusted peer
|
||
- later, maybe keep completed files and restart only the interrupted file
|
||
- avoid byte-offset resume until there’s a strong reason
|
||
|
||
6. **Expand scenario coverage**
|
||
|
||
I’d add cases for:
|
||
|
||
- sender disconnect mid-stream
|
||
- receiver cancel mid-stream
|
||
- corrupted/truncated stream fails and leaves no `local/`
|
||
- already-installed game rejects streamed install
|
||
- multi-archive `.eti` roots stream in sorted order
|
||
|
||
7. **Clean product semantics**
|
||
|
||
Decide how the UI labels this state. It is installed but not downloaded, so
|
||
“Local only” is technically correct, but users may need a clear affordance
|
||
like “Installed, not shareable”.
|
||
|
||
My recommended next slice: make the provider abstraction final-ish, then
|
||
implement a real one-pass provider. Everything else builds cleanly on that.
|