Notes sur l'architecture

Motivation

Ortho4XP est un projet amateur qui a été écrit pour remplir un objectif précis, puis amendé pour de nouvelles fonctionnalités, sans vision architecturale globale. Il est difficilement maintenable et les améliorations ne sont pas des plus aisées.

Son objectif global se prête bien à une approche modulaire.

Progressivité

Ce document décrit l'architecture cible. Pour ne pas se lancer dans un objectif inatteignable, la base de code existante sera conservée, et éventuellement maintenue si la charge de travail reste raisonnable.

À l'heure actuelle le dépôt est personnel et mon travail se concentra sur mon cas d'usage propre : sous Linux et essentiellement en ligne de commande. Pour le reste tout dépendra des contributions externes et l'approche modulaire devrait avoir pour effet collatéral de mieux se préter à l'intégration de nouveaux traitements.

Tout nouveau développement devra donc être réalisé dans l'architecture cible tout en maintenant la compatibilité avec l'existant.

Par convention, le répertoire de travail de l'architecture cible devra être le répertoire principal utilisé par l'ancienne base de code. Cependant l'architecture cible permettra de distinguer le répertoire de travail (dont le support physique sera rapide) du répertoire d'archive (support physique éventuellement lent). Cela aura comme effet de bord que la génération finale d'une tuile par la nouvelle architecture la rendra invisible depuis l'interface existante.

Architecture cible

Deux principes doivent être mis en œuvre :

• Modularité
  Un module est un traitement spécifique sur une tuile passée en paramètre (assimilée à son répertoire). Il postule la présence de Path (chemins d'accès) dans le répertoire de la tuile, que sont les Requires de module, et produit d'autres Path en résultat que sont les Provides du module.
• Autonomie
  Les fichiers .py dans le répertoire modules/ doivent être exécutable et fournir une fonction main qui prend les arguments à l'image de l'exécutable. Cette fonction retourne 0 en cas de succès du traitement. Le common.py, seul non exécutable, regroupe l'outillage du développeur du module.

C'est donc l'exécution d'une série de modules qui permettra d'aboutir à la production de la tuile finale, exploitable directement par X-Plane. Chaque module fournit un ou plusieurs Path nécessaires aux modules qui lui succèdent dans les traitements.

Dans l'attente d'une documentation complète sur l'écriture d'un module on pourra utilement s'inspirer de l'existant. Tout nouveau module devra utiliser des Path présent sur la liste Path ; cette liste est centralisée et toute modification dessus doit faire l'objet d'une demande spécifique pour éviter les conflits.