Oui, ce serait bien mieux.
Moi je n’y vois aucun problème.
L’indexation des données
Comme vous le savez, le nœud est le cœur du réseau. S’il bug, c’est tout le reste qui s’effondre. Or il est un fait établi désormais que plus un programme comporte de lignes de code et plus statistiquement celui-ci comporte des bugs. Donc, évitons de lui faire porter la responsabilité de répondre à des besoins qui ne sont pas les siens.
D’ailleurs vous comprenez bien que les besoins d’un client ne sont pas forcément ceux d’un autre, par exemple Cesium touche un peu à toutes les données (WoT, transactions) tandis que WotWizard se fiche des transactions. Et donc si l’on commence à assouvir les besoins de ces clients, où allons-nous nous arrêter ? Faudra-t-il demain créer un index très spécial pour pouvoir remonter les transactions insérées un jour de pleine lune pour le fameux service “Transactions Haute Marée” ?
Par conséquent vous comprenez ma position : le nœud doit avoir le moins de responsabilités possible et se concentrer sur son unique rôle : assurer le respect du protocole. C’était le sens de WS2P, qui permet à la fois aux nœuds de se protéger d’attaques DoS et de limiter le trafic réseau à l’exécution du protocole, donc d’éviter le trafic lié aux clients.
J’ai bien conscience aussi que sans clients, on a beau avoir un protocole hyper secure et un code sans bugs, ce même code ne sert alors à rien !
Mais c’est justement là qu’entrent en jeu les indexeurs, programmes tiers capables d’extraire l’état d’un nœud, de le transformer afin de rendre ces données exploitables dans un but précis. Ainsi un indexeur dont le rôle est de fournir des infos pour un WotWizard n’organise pas ses données de la même façon qu’une place de change qui elle ne s’intéresse qu’aux transactions, ou que ne le fait le Pod Cesium+ qui s’intéresse aux données de façon plus large mais toujours orientée vers l’utilisateur lambda, ou encore que ne le ferait l’indexeur Haute Marée.
Existe-t-il déjà un indexeur qui serait capable de fournir rapidement les informations demandées par @kimamila ? La réponse est oui ! Le nœud Duniter peut fonctionner en mode miroir, son rôle n’est alors pas tant de faire respecter le protocole que d’en conserver une image, pour des besoins d’exploitation qui regardent son hébergeur. Celui-ci pourrait par exemple y installer le module GVA API afin de répondre à un besoin d’extraction de données plus performant et adapté que BMA aux besoins basiques de clients Duniter.
Et la suppression de sources ?
Un module Duniter peut tout à fait stocker ses propres données, et par exemple mémoriser les sources supprimées ainsi que les oublier en cas de revert. C’est très simple à réaliser.
Je résume donc ma pensée :
- le code du cœur doit se concentrer uniquement sur le protocole, et ce code est pensé exclusivement pour les membres calculants
- pour les besoins externes, créer des services tiers qui indexent eux-mêmes les données des blocs. Il existe déjà un indexeur facile à réutiliser : le nœud Duniter en mode miroir, auquel il faut simplement rajouter une API. Si le mode de stockage du nœud n’est pas adapté aux besoins, privilégier le service externe au module Duniter.
Pas sûr que ma réponse vous satisfasse !