pastilhasandClaude Opus 5
864dd16355
The sixth plugin out, immediately after photos. A sidecar, a proxy router and 29 web files; no db/ directory, because there are no tables. ── The one thing that is not self-contained ── The connection lives in `service_connections`, a CORE table, reached through getServiceConnection/saveServiceConnection/getServiceCredentials. This plugin declares no schema. Deliberate: that table is the app store's shared credential store, keyed on (user_id, service), already encrypted at rest and already read by app-store/effects.ts. A private copy of the same three columns would be a second place the same fact could live, and the runbook is explicit that a move plus a data-format change gives any failure two causes. The cost, stated rather than hidden: this plugin depends on a core facility it does not own, and would break if that table changed shape. Photos, by contrast, owns photos_config outright. ── 38 palette classes paid down, mapped by meaning ── blue downloading / download speed -> info cyan checking (verifying) -> busy emerald seeding / complete -> success amber queued / stalled / warnings -> warning Collapsing blue and cyan into one tone would have lost a real distinction in the status dot, so `checking` went to `busy` — in-progress work, which is what that tone is for. ── A near-miss worth recording ── The first copy globbed *.tsx and *.ts and silently missed detail/ and dialogs/ — ten components. tsgo caught it as ten "cannot find module" errors. Worth stating because it is quiet in the other direction: had those been imported lazily, the typecheck would have passed and the panels would have broken at runtime. Check the directory tree, not the file glob. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
# Transmission
|
|
|
|
Your torrent daemon, driven from Officer.
|
|
|
|
Transmission does not install or supervise the daemon and holds no torrents of its own. You point it at a
|
|
daemon's RPC endpoint; it speaks that protocol for you and keeps the credentials server-side, so no
|
|
device ever carries them.
|
|
|
|
## What you get
|
|
|
|
- **The queue**, virtualised — thousands of torrents scroll without the list breaking a sweat.
|
|
- **Per-torrent detail**: general, files (with per-file priority and wanted/unwanted), peers, trackers.
|
|
- **The usual verbs** — add by magnet or file, remove with or without data, move, relabel, set options.
|
|
- **Stats and speed limits**, including the alternative-speed schedule.
|
|
|
|
## What you need
|
|
|
|
**A Transmission daemon you already run**, with RPC enabled — its URL, the RPC path (usually
|
|
`/transmission/rpc`), and a username and password if it requires them.
|
|
|
|
Nothing else. No system packages, no host binaries.
|
|
|
|
## Setup
|
|
|
|
1. Install the plugin.
|
|
2. Open **/transmission → Connection** and enter the daemon's address and credentials.
|
|
3. It probes the RPC endpoint and stores the connection encrypted, server-side.
|
|
|
|
## Worth knowing
|
|
|
|
- **The connection is stored in a core table, not this plugin's.** `service_connections` is the app
|
|
store's shared credential store, keyed by account and service. This plugin ships no schema of its own —
|
|
see PLUGIN.md for why that is deliberate and what it costs.
|
|
- **It polls.** A torrent client's whole value is live numbers, so the panels refresh on a timer while
|
|
open. That is a real difference from, say, a bookkeeping app, and it is intentional.
|
|
- **It is a client, not a supervisor.** If the daemon stops, this reports that it cannot reach it. It
|
|
will not start it for you.
|