Architettura

Come si integrano i componenti di Mister Download Manager.

Crates

Le dipendenze puntano verso l'interno: app, cli, mcp e nmhost usano engine e ipc; il motore non sa nulla dell'interfaccia utente. L'app vede il motore solo attraverso i suoi eventi (progresso, snapshot della tabella dei segmenti, completato, fallito).

Motore

Download
 ├─ probe()              size, resumable?, validators (ETag / Last-Modified), file name
 ├─ Planner (pure)       segment table: when a connection is free, the largest remaining
 │                       part is split in half (planner.rs, tested by random simulation)
 ├─ Worker × N           one HTTP/1.1 connection each, reused across segments; slow ones
 │                       are dropped and their part re-split
 │    └─ writes at its offset into <name>.mdm.part (created sparse)
 ├─ HostLimits           learns how many connections each server accepts
 ├─ Limiter (shared)     per-download and global token buckets
 ├─ State                segment table saved atomically (craft-atomic) for crash-safe resume
 └─ events → channel     Progress, Done, Failed

Quando ogni segmento è completato, il file temporaneo viene controllato rispetto alla dimensione prevista e rinominato nella sua posizione finale; la data del file può seguire quella del server.

FTP e FTPS (ftp.rs) passano attraverso lo stesso pianificatore, worker e stato: un segmento è REST + RETR su una sessione di controllo invece di un GET con range, SIZE e MDTM sostituiscono le intestazioni, e le sessioni sono raggruppate per download e riutilizzate tra i segmenti.

App

Una finestra egui disegnata a coordinate fisse in pixel, più una viewport immediata per ogni finestra di dialogo. app.rs contiene lo stato (download, code, impostazioni, la selezione dell'elenco) e trasforma i comandi di menu, barra degli strumenti, tastiera e IPC in azioni. Ogni finestra di dialogo è un modulo a sé stante e restituisce un Outcome (aperto, chiuso, completato con un valore). Le chiamate solo per Windows sono confinate a win32.rs e le loro controparti per Linux e macOS a unix.rs (a partire dalla sessione, l'host dei browser, i suoni, mostra nella cartella, il gestore dei crash); ogni altro file è Rust sicuro e portatile. I font provengono dal sistema: la cartella Fonts di Windows, i font di sistema di macOS, fontconfig su Linux (theme.rs).

L'elenco dei download e le impostazioni vengono salvati atomicamente in %APPDATA%\misterdownloadmanager\ (downloads.json). L'host del browser legge lo stesso file per le regole di cattura, quindi una modifica in Opzioni si applica al prossimo download catturato.

Integrazione con il browser

page ──► extension ──native messaging──► mdm-nmhost ──ipc──► app

L'estensione chiede all'host quali tipi di file acquisire, controlla ogni download rispetto a essi e annulla il download del browser solo dopo che l'app lo ha accettato; altrimenti il browser lo mantiene.

Traduzioni

Ogni testo mostrato dall'interfaccia utente passa attraverso crate::i18n (cataloghi craft-i18n, i18n/<locale>.tsv). tools/i18n/extract.py ricostruisce i18n/en.tsv dalla sorgente, con una nota per i traduttori su ogni testo (cos'è, dove appare, i suoi segnaposto).

Test e benchmark

cargo testesegue test unitari e download end-to-end contro mdm-labserver con errori iniettati (connessioni lente, interrotte e rifiutate, server senza range, file che cambiano). tools/bench esegue il confronto di velocità pubblicato; i suoi dati grezzi si trovano in docs/bench/.