Désolé pour ma non-réactivité à ce qui s’est passé sur GitLab ces derniers temps. J’ai enfin des vacances sans examens à la rentrée donc je vais pouvoir lire les notifs.
Je vais commencer par inclure l’oracle dans l’exécutable duniter, en sous-commande, pour simplifier la compilation, la livraison et l’installation. #140
Si c’est possible ce serait mieux de pouvoir le lancer en même temps que Duniter. À voir les avantages/inconvénients de coupler les deux à l’exécution (thread) : en cas de plantage on perd les résultats, mais la communication est plus rapide et propre (ni fichier ni RPC).
Le paramètre max_depth de 5 pas n’est pas strictement nécessaire dans le runtime car seul l’oracle l’utilise.
Cependant si on veut le modifier il faut que les calculateurs pensent à mettre à jour l’oracle ou à changer l’argument à la main. Grâce à la règle de la médiane, avec un ensemble constant de calculateurs la nouvelle valeur devrait entrer en vigueur dès que plus de la moitié a mis à jour. Mais si l’ensemble varie, les résultats seront un peu aléatoires pendant la transition.
Faut-il ajouter ce paramètre dans le runtime pour faciliter sa mise à jour par les mêmes processus de décision que les autres paramètres, même s’il apparaît comme du code mort dans le runtime ?
Avec toutes les macros je pense qu’un paramètre inutilisé n’est jamais du code mort selon le compilateur (puisqu’il est exposé dans des APIs).
C’est justement un problème : il n’y a pas de moyen systématique de vérifier qu’un paramètre ou une constante runtime est effectivement utilisé. Il faut juste y penser.
Un inconvénient d’intégrer du code subxt dans Duniter :
La compilation dépend du fichier metadata, qui dépend d’une compilation préalable de Duniter.
En cas de changement des metadata, il faudra donc d’abord compiler Duniter sans la feature distance-oracle pour mettre à jour le fichier et pouvoir le compiler avec la feature.
Si d’autres fonctionnalités subxt sont ajoutées, tout ce code devrait être désactivable avec une feature unique.
Peut-être que cela risque de casser la CI en cas de changement de l’API de distance ?
Effectivement, j’essaye de rebase !226 et ça pose problème.
Il faudrait avoir un mode alternatif pour que subxt aille chercher ce qu’il lui faut directement dans le code plutôt que dans les metadata.scale, ce serait plus pratique.