Arquitetura

Como as partes do Mister Download Manager se encaixam.

Crates

As dependências apontam para dentro: app, cli, mcp e nmhost usam engine e ipc; o motor não sabe nada da interface. A aplicação vê o motor apenas através dos seus eventos (progresso, instantâneos da tabela de segmentos, concluído, falhou).

Motor

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 todos os segmentos estão concluídos, o ficheiro de parte é verificado em relação ao tamanho esperado e renomeado para o local; a data do ficheiro pode seguir a do servidor.

FTP e FTPS (ftp.rs) passam pelo mesmo planeador, trabalhadores e estado: um segmento é REST + RETR numa sessão de controlo em vez de um GET com intervalo, SIZE e MDTM substituem os cabeçalhos, e as sessões são agrupadas por transferência e reutilizadas entre segmentos.

Aplicação

Uma janela egui desenhada para coordenadas de pixel fixas, mais uma viewport imediata por diálogo. app.rs mantém o estado (transferências, filas, definições, a seleção da lista) e transforma comandos de menu, barra de ferramentas, teclado e IPC em ações. Cada diálogo é o seu próprio módulo e retorna um Outcome (aberto, fechado, concluído com um valor). As chamadas apenas para Windows estão confinadas a win32.rs e as suas contrapartes para Linux e macOS a unix.rs (começando com a sessão, o anfitrião dos navegadores, sons, mostrar na pasta, o manipulador de falhas); todos os outros ficheiros são Rust seguro e portátil. As fontes vêm do sistema: pasta Fonts do Windows, fontes do sistema do macOS, fontconfig no Linux (theme.rs).

A lista de transferências e as definições são guardadas atomicamente em %APPDATA%\misterdownloadmanager\ (downloads.json). O anfitrião do navegador lê o mesmo ficheiro para as regras de captura, então uma alteração em Opções aplica-se à próxima transferência capturada.

Integração com o navegador

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

A extensão pergunta ao anfitrião quais os tipos de ficheiro a capturar, verifica cada transferência em relação a eles e cancela a transferência do navegador apenas depois de a aplicação a ter aceite; caso contrário, o navegador a mantém.

Traduções

Todo o texto que a interface mostra passa por crate::i18n (catálogos craft-i18n, i18n/<locale>.tsv). tools/i18n/extract.py reconstrói i18n/en.tsv a partir da fonte, com uma nota para os tradutores em cada texto (o que é, onde aparece, os seus marcadores de posição).

Testes e benchmarks

cargo testexecuta testes unitários e transferências de ponta a ponta contra mdm-labserver com falhas injetadas (ligações lentas, perdidas e recusadas, servidores sem intervalos, ficheiros em mudança). tools/bench executa a comparação de velocidade publicada; os seus dados brutos estão em docs/bench/.