path-types

Types de chemins

Appliquez ces directives lors de la définition de nouveaux types. Ne modifiez le code existant que lorsque cela est explicitement demandé, et limitez les modifications au strict nécessaire. Traitez ces règles comme l'état cible d'une migration en cours ; si la conformité est difficile, demandez à l'utilisateur comment procéder.

• Dans les types de protocole du serveur d'application, utilisez LegacyAppPathString pour la rétrocompatibilité pendant la migration des URI. À la frontière du protocole, convertissez-le en PathUri et utilisez PathUri en interne. Pour la logique locale à l'hôte, comme certaines valeurs de configuration, utilisez AbsolutePathBuf ou PathBuf à la place.
• Dans les types de protocole du serveur d'exécution, utilisez PathUri. En interne, utilisez PathUri ou AbsolutePathBuf selon le cas.
• Dans les dépendances partagées par les deux serveurs, utilisez PathUri ou des API séparées qui découplent leurs cas d'utilisation.
• Les arguments d'appel d'outil que le modèle est censé générer doivent être désérialisés comme des String normales avec un code de gestion de chemin spécifique à la fonctionnalité.

Exigences de migration

Gardez ces exigences à l'esprit lors de la migration du code pour respecter les directives ci-dessus :

• les clients existants du serveur d'application continuent d'envoyer et de recevoir des chaînes de chemin natif héritées
• le serveur d'application peut conserver et manipuler des URI de chemin de plateforme étrangère
• les API du serveur d'exécution utilisent des URI file://
• l'opération locale uniquement ne doit pas modifier le texte visible par le modèle
• les arguments d'outil du modèle peuvent contenir des chemins relatifs ou absolus bruts pour tout système d'exploitation
• le raisonnement sur les chemins doit fonctionner avant que l'environnement associé ne soit en ligne
• les URI ne peuvent pas encoder explicitement la convention de chemin ou le système d'exploitation de l'exécuteur
• les utilisateurs ne doivent pas configurer explicitement le système d'exploitation/la convention de chemin de l'environnement
• les URI ne doivent pas encore être stockés dans les rollouts, les bases de données ou tout autre stockage persistant
• erreurs de conversion de chemin : fermé sur échec pour les chemins critiques pour la sécurité, ouvert sur échec pour l'interface utilisateur/les diagnostics
• préférez les petites méthodes ciblées sur PathUri ou LegacyAppPathString plutôt que des aides locales
• représentez les valeurs PathUri comme des URI dans les diagnostics

Il est acceptable que la conversion entre chemins et URI soit un peu imparfaite tant qu'elle fera ce qu'il faut pour les utilisateurs réels.

La migration vers les URI ne doit pas ajouter de nouveaux modes d'échec significatifs. Nous devrons faire remonter des erreurs dans certains endroits qui étaient auparavant infaillibles, mais cela doit être limité au strict minimum.