Je relance un peu cette discution au sujet de la liste des DU consumés avec GVA.
Pour le moment GVA ne semble pas non plus afficher les DU consumés (exemple avec ma clé membre, ouioui j’ai consumé tous mes DU à cause de mes tests GVA lol):
Est-ce que tu as prévu de faire évoluer cette commande pour les afficher @elois ou faut il que les clients continuent de contourner le problème ?
Edit: Je vois que ça a été ajouté à la wishlist de GVA par Moul donc je suppose que c’est prévu ^^
Pourquoi ne joue tu pas avec les sources de monnaies sur la Ğ1-test ?
Attention ne pas confondre une liste de vœux avec ce qui sera effectivement fait. La liste de vœux m’est très utile, car elle me permet de savoir ce qui est souhaité par les dev des clients, mais je ne peux pas m’engager à tout implémenter.
Certaines demandes ont des implications plus ou moins impactantes sur le code coté serveur et sa complexité, plus le coût coté serveur est élevé plus il faut que la demande sois justifie par une réelle plus-value pour l’utilisateur qui ne puisse pas être apportée à l’utilisateur d’une autre manière plus simple.
J’en suis encore trop tôt dans le développement pour entamer la wishlist et discuter point par point de toutes les demandes, ça va se faire au fur et à mesure 
Concernant la liste des DU consommé, pour le moment je ne comprends pas l’intérêt d’une telle fonctionnalité, quel est le besoin derrière ? qu’est-ce que cela apporte à l’utilisateur ? n’y a t-il pas moyen de répondre au réel besoin autrement ?
Le besoin (j’ai le problème côté Sakia), ne s’exprime pas en ces termes.
Le besoin utilisateur c’est :
Pour cela, un client va se tourner (en BMA), vers la requête de l’historique des sources (devenu l’historique des sources non consommées).
C’est déjà un contournement, et pas du tout fiable car l’historique, maintenant, n’est pas immuable. Il est variable car les sources consommées disparaissent.
Les clients désirent donc :
Pourquoi ?
Je pense plutôt fournir :
number, blockchainTime et dividendAvec ça tu peux construire facilement les DU créé entre 2 dates, et ceux sans avoir besoin de faire plusieurs requêtes.
Je préfère fournir des méta-données qui permettent de recréer facilement à peu près ce qu’on veut, ça permet de simplifier grandement le code coté serveur et de répondre à beaucoup de besoins avec peu.
Parce que. 
Un compte monétaire affiche toutes les recettes et les dépenses. Pourquoi veux-tu exclure les DU qui pourtant entre dans le calcul du solde.
Moi, en tant que développeur de client, me dire de faire deux requêtes au lieu d’une n’est pas souhaitable sur cette API car elle est censée être dédiée aux clients. Le choix de graphQL va d’ailleurs dans ce sens, faire plus de choses côté serveur pour optimiser les requêtes des clients.
Si on ne part pas dans cette direction là, alors il faut qu’on discute sérieusement de ce que l’on veut faire avec GVA.
Oui bien sûr. Je pensais que comme tu n’avais pas commenté cette liste que tu n’avais rien à y redire, mais je comprends que c’est beaucoup trop tôt pour que tu t’y itnéresse
Pour ma part c’est simplement pour calculer le solde de chaque compte membre. Actuellement je somme correctement les entrées/dépenses grâce à l’historique généré par GVA, mais je ne sais pas comment y ajouter la somme des DU générés depuis le début ? Sachant que dans un cas complexe, le membre a pu ne plus l’être pendant un certain temps avant de le redevenir…
Même avec BMA en réalité je ne sais pas comment faire. J’ai essayé de regarder le code de Silkaj mais je ne comprends pas encore comment fait @Moul (je ne crois pas que cela se joue dans duniterpy si ?)
Mais il y a peut être un moyen de contourner ce soucis que je n’ai pas vue
Le champ dividend ici serait la valeur du DU dans chaque bloc ?
Dans ce cas cas pour calculer le solde d’un compte il faut d’abord que je récupère ses dates d’entrée/sortie au status de membre, et que je fasse autant de requête que d’entrée/sortie dans ce status.
Je ne veux rien exclure je demande le besoin, tu y a répondu, c’est ok
Où ai-je dit que tu devrais faire 2 requêtes ? Je t’ai proposé une solution en une seule requête
Faire plus de choses ne doit par signifier «tout faire». Le but n’est pas de passer de l’extrême «tout coté client» à l’extrême «tout coté serveur». Il y a plus de contributeurs motivés coté client et plus de codebase ou s’inspirer, car plusieurs clients aboutis.
Le code de Duniter est critique (sans lui plus de monnaie) et déjà trop complexe et immaintenable. Mon objectif est de le simplifier tout en le rendant plus maintenable et en étant plus orienté sur les besoins des clients. Mais «plus orienté sur X» ne doit pas signifier «tout faire pour X».
Ce sera donc la voie du milieu, avec des compromis de chaque côté, et des discussions constructives sur chaque besoin. Très souvent, il existe des alternatives pour répondre au même besoin de manière plus simple.
Souhaitant chasser le plus possible toute complexité inutile, pour chaque demande impliquant de la complexité je questionnerai le besoin et réfléchirai aux alternatives possibles
Concernant la demande «l’historique des DU créé pour un compte membre, entre deux dates», je comprends et j’accepte
Dans ce cas tu n’as donc pas besoin des DU consommé, il suffit de demander une requête donnant directement la balance d’un compte, pour le coup ça c’est simple à faire
EDIT: @poka en attendant tu te prends trop la tête pour rien, il te suffit de sommer les sources d’un compte (UTXOs + DUs).
C’est pas moi qui calcule le solde : c’est Silkaj. C’est principalement @Tortue qui a implémenté cette partie, que moi et surement matograine et d’autres se sont appropriés et maintiennent cette partie.
À partir des sources de monnaie d’une clé publique il est possible d’en faire la somme pour obtenir le solde :
Note : les sources de monnaies non consommés UTXO ne contiennent pas les DU consommés.
Pardon, comme tu as séparé les deux infos retournées, j’ai pensé que c’était en deux requêtes, my bad ! 
Oui je te comprend tout à fait et je suis d’accord. Mais si GVA est un module bien séparé du cœur, et qu’il est possible de lui ajouter des fonctionnalités avancées sans complexifier le cœur, allons-y.
Comme je ne sais pas ce qui nécessite de complexifier le cœur dans nos souhaits de devs clients, dis le nous. Mais si c’est possible juste dans le module GVA, même s’il faut attendre l’aide de plus de contributeurs, faisons-le.
Besoins client de base non exhaustif :
Je vais faire un beau tableau en wiki sur le billet des souhaits clients comme ceci :
| Fonctionnalité | requête(s) BMA | requête(s) GVA |
|---|---|---|
| Afficher le solde | - requête sources DU (non-consommées) | A faire |
| - requête sources TX |
etc, etc…
Je suis en train de développer GVA dans ce sens, avec sa propre DB et sa propre crate, afin de bien séparer ce qui est là pour GVA de ce qui est là pour d’autres raisons, et de permettre la possibilité d’avoir un nœud Duniter sans GVA pour ceux qui souhaitent un nœud léger.
Mais ce sera quand même dans le même dépôt, maintenu par les mêmes contributeurs pour l’instant, et comme c’est dans le même processus si GVA crache ça fait crasher le cœur, donc son développement impacte forcément la stabilité du cœur.
De plus, pour tout code que je m’engage à maintenir je refuse toute complexité inutile, donc je me limiterai aux besoins de base ou simple à implémenter + les fonctionnalités essentielles permettant à des programmes complémentaires d’en faire plus : à savoir la souscription à l’ajout et au retrait d’un bloc de la blockchain locale du nœud.
Ça, ça va c’est des besoins de base que je pense implémenter.