Architecture

Comment les composants de Mister Download Manager s'assemblent.

Crâtes

Les dépendances pointent vers l'intérieur : app, cli, mcp et nmhost utilisent engine et ipc ; le moteur ne sait rien de l'interface utilisateur. L'application ne voit le moteur qu'à travers ses événements (progression, instantanés de la table des segments, terminé, échoué).

Moteur

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

Lorsque tous les segments sont terminés, le fichier partiel est vérifié par rapport à la taille attendue et renommé à sa place ; la date du fichier peut suivre celle du serveur.

FTP et FTPS (ftp.rs) passent par le même planificateur, les mêmes travailleurs et le même état : un segment est REST + RETR sur une session de contrôle au lieu d'un GET, SIZE et MDTM à plage remplacent les en-têtes, et les sessions sont regroupées par téléchargement et réutilisées entre les segments.

App

Une fenêtre egui peinte à des coordonnées de pixels fixes, plus une fenêtre d'affichage immédiate par dialogue. app.rs contient l'état (téléchargements, files d'attente, paramètres, sélection de la liste) et transforme les commandes de menu, de barre d'outils, de clavier et d'IPC en actions. Chaque dialogue est son propre module et renvoie un Outcome (ouvert, fermé, terminé avec une valeur). Les appels spécifiques à Windows sont confinés à win32.rs et leurs équivalents Linux et macOS à unix.rs (à commencer par la session, l'hôte des navigateurs, les sons, l'affichage dans le dossier, le gestionnaire de crash) ; tout autre fichier est du Rust sûr et portable. Les polices proviennent du système : le dossier Polices de Windows, les polices système de macOS, fontconfig sur Linux (theme.rs).

La liste des téléchargements et les paramètres sont enregistrés atomiquement dans %APPDATA%\misterdownloadmanager\ (downloads.json). L'hôte du navigateur lit le même fichier pour les règles de capture, de sorte qu'un changement dans les Options s'applique au prochain téléchargement capturé.

Intégration au navigateur

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

L'extension demande à l'hôte quels types de fichiers prendre, vérifie chaque téléchargement par rapport à ceux-ci, et n'annule le téléchargement du navigateur qu'après que l'application l'ait accepté ; sinon, le navigateur le conserve.

Traductions

Chaque texte affiché par l'interface utilisateur passe par crate::i18n (catalogues craft-i18n, i18n/<locale>.tsv). tools/i18n/extract.py reconstruit i18n/en.tsv à partir de la source, avec une note pour les traducteurs sur chaque texte (ce que c'est, où il apparaît, ses espaces réservés).

Tests et benchmarks

cargo testexécute des tests unitaires et des téléchargements de bout en bout contre mdm-labserver avec des pannes injectées (connexions lentes, interrompues et refusées, serveurs sans plages, fichiers changeants). tools/bench exécute la comparaison de vitesse publiée ; ses données brutes se trouvent dans docs/bench/.