@elois soulève dans cette remarque une question intéressante. Souhaite-t-on ajouter plein de fonctionnalités comme l’oracle de distance, le précalcul de la règle de distance à destination de l’indexeur, ou autre, tout ça comme sous-commandes de Duniter (même Ğ1cli pourrait devenir une sous-commande de Duniter dans l’idée), ou préfère-t-on distribuer des binaires distincts, quitte à les sortir du dépôt Duniter et gérer leur évolution à part ? Je vois des arguments en faveur des deux, mais j’aimerais bien savoir ce que autres attendent de Duniter en matière d’organisation. Donnez vos avis en message et je ferai un tableau récapitulatif.
1 Like
Je penche plus vers la solution d’Éloïs.
Pour donner plus de contexte, historiquement, tuxmain a choisi de faire de l’oracle de distance un binaire séparé, car c’était plus simple pour lui de procéder ainsi et je n’étais pas disponible pour aider. Mais c’était un mauvais design dès le départ : cela force à inclure subxt en production pour échanger les données de la WoT via RPC, ce qui est très inefficace.
Je n’ai jamais approuvé ce design. C’est pour cela que j’avais créé le ticket #293. Mon plan est de fusionner/refondre l’oracle de distance dans le binaire Duniter afin de gagner en efficience, en lisant directement la base de données qui contient les informations. Substrate permet de faire cela proprement avec un trait StorageProvider. Je connais bien ce mécanisme, car nous l’utilisons à mon travail.
Je comptais faire cela avant la migration v2, mais j’ai eu des problèmes de santé.
Tout ça pour dire que j’ai la très mauvaise impression que cette MR cherche à poursuivre un mauvais design que je n’ai jamais approuvé, en créant encore un autre binaire séparé. Cela est moins efficient, plus gourmand en espace disque, complexifie les releases de Duniter, et alourdit également les workflows de développement et de test.
Il est vraiment important pour moi que l’on revienne à un seul binaire pour Duniter. Je compte faire cela dans les prochaines semaines, car cela va me faciliter les autres évolutions que je souhaite mettre en place ensuite, notamment la simplification du workflow des tests end-to-end afin de pouvoir en ajouter davantage.
EDIT:
Pour l’oracle de distance, de mon point de vue, cela doit faire partie de Duniter lui-même, car les forgerons doivent l’exécuter. Il me semble essentiel de pouvoir être forgeron en installant et en mettant à jour un seul binaire qui contient tout le nécessaire pour l’être (même si le calcul de distance restera un opt-in via un flag CLI désactivé par défaut).
Pour le précalcul de distance, je suis favorable à l’intégration de cette fonctionnalité dans Duniter afin de réutiliser le même code et d’éviter de maintenir séparément un code de calcul de distance distinct. Plus généralement, je ne suis pas contre l’ajout de fonctionnalités dans Duniter lui-même, à condition que Duniter reste un seul et unique binaire.
7 Likes
Ok, ça me parle comme justification. Je me suis aligné sur le design précédent sans le remettre en question, mais c’est en effet beaucoup mieux de passer par le StorageProvider. Pour poursuivre la logique, on pourrait même ajouter le calcul périodique de la règle de distance dans le offchain storage et servir le résultat via l’API RPC. Côté indexeur, ça permettrait de simplement requêter périodiquement l’API RPC du noeud sur lequel ils indexent pour ajouter le résultat dans leur base postgres.