Les pages et les outils

Retrouver les octets d’une page

Dans la version de développement, nous modifions un fichier et le navigateur affiche le résultat. Dans la version distribuée, la même page peut être contenue dans l’exécutable. Le serveur HTTP n’a pas besoin de connaître la différence pour répondre à la demande.

Il demande la ressource à un fournisseur dont l’opération open(std::filesystem::path) renvoie un std::optional<fs::File>. Si le fournisseur ne connaît pas cette ressource, il renvoie une absence de résultat. fs::Multi permet d’en essayer plusieurs dans un ordre défini ; le premier qui répond fournit le fichier.

Nous pouvons ainsi choisir le stockage sans changer les URL de la page. Ce choix n’efface pas les questions de durée de vie : si le fichier emprunte des octets, leur propriétaire doit les conserver pendant la lecture.

L’ordre des fournisseurs a un effet

Pour une image de l’application, donner la priorité au répertoire de développement est utile : le fichier que nous venons de modifier apparaît immédiatement. Pour le code du pont, ce serait dangereux. Un ancien WebFront.js resté dans ce répertoire pourrait ne plus correspondre au codec C++.

La composition par défaut protège donc les modules du pont. Elle consulte ensuite les fournisseurs autorisés et la racine documentaire de développement, avant la page de secours. Si aucune racine documentaire n’a été donnée, elle n’ouvre pas de fichiers locaux.

Le petit ensemble de ressources du cœur est conservé dans une liste fermée. Le test MinimalCoreAssets et le budget de l’ADR-016 nous aident à repérer une dépendance qui y entrerait par inadvertance. Ajouter un outil à cette liste demande un choix d’architecture, pas seulement une ligne d’inclusion.

Les outils n’ont pas à voyager partout

Pour développer l’interface, nous avons besoin du compilateur et des outils de test. Une personne qui utilise l’application terminée n’en a généralement pas besoin. Le bootstrap permet de charger séparément une distribution développeur épinglée, après vérification de son intégrité.

Dans cet environnement, la résolution des paquets, la compilation par esbuild-wasm, le contrôle des types et les tests s’exécutent dans le navigateur. Le projet conserve les versions exactes et leurs empreintes, afin qu’une autre machine puisse retrouver les mêmes dépendances.

Le dépôt WebFront utilise lui aussi ces outils, avec --manifest-dir js/developer. Il faut donc pouvoir reconstruire l’environnement à partir d’un bootstrap connu. Lors d’une publication, nous vérifions d’abord la nouvelle archive à son adresse de distribution ; le pin peut ensuite être déplacé vers elle.

Deux sortes d’en-têtes générés

En parcourant le dépôt, nous trouverons des ressources générées à deux endroits. Il est facile de les confondre au début.

Les sources du cœur sont dans js/core/. Les outils CMake les transforment en en-têtes versionnés, que les constructions C++ ordinaires consomment. Des tests vérifient que ces en-têtes correspondent encore aux sources lisibles.

Les ressources de notre application suivent un autre chemin. wf embed compile son interface et produit son fournisseur C++. Celui-ci lui permet de retrouver ses pages sans charger les outils de développement.

Dans les deux cas, le serveur doit encore choisir un encodage acceptable et appliquer les limites de décodage. Un fichier au bon nom ne nous renseigne ni sur la validité de ses octets ni sur la taille qu’ils occuperont après décodage.