5 messages ont été scindés en un nouveau sujet : RFC GVA > movementsByPubkey() et time redressé
Dernière question 
Pour ma part, pas d’implémentation en dur pour l’instant (pas de classes avec les query transposées en python). Seulement des tests de connection, de récupération récursive du schéma. Il faut faire les query à la main en GraphQL. donc je m’adapte à ce qui sera en place.
Donc pour la RFC je laisse la main, n’ayant pas le temps de m’en occuper. Je vous fais confiance.
Voir plutôt avec @elois qui a démarré une implémentation serveur.
Je commencerai à critiquer la RFC quand j’en aurai besoin pour Sakia, donc pas avant 2020… 
Désolé de mon absence dans ce fil, mais au final je suis content que vous ayez réfléchi et pris les décisions sans moi 
Et puis je n’ai pas grand-chose à redire :
Ce schéma n’était qu’un POC pour le Cesium v2 de @kimamila, vous pouvez l’oublier. Je suis d’accord avec vous sur le principe de spécifier un maximum avant d’implémenter quand c’est possible, c’est un luxe que je n’ai pas eu pour BMA. Cela n’empêche toutefois pas la réalisation de POC pour ceux qui le veulent, c’est ce que j’ai fait. Cela permettent aussi de révéler des problématiques légèrement en amont de l’implémentation.
Mais bref, ce n’était vraiment pas une spécification ce schéma
Je suppose que c’est une phrase raccourci car GVA n’est pas obligatoire pour une implémentation de Duniter (= DUBP) vu que c’est de niveau réseau (= DUNP). Il existera certes une implémentation GVA pour Duniter et Durs, mais pas sûr que ça intéresse Junidev ou d’autres développeurs de nœuds.
Aussi pour Duniter il s’agit d’un module externe. D’ailleurs ce module va peut-être exploiter sa propre BDD dédiée, adaptée aux contraintes de critères de recherche de l’API GVA. Ce serait bien car cela me forcerait à formaliser l’API interne de Duniter pour les événements liés à la blockchain.
Oui optionnelle en argument, mais obligatoire en réponse pour indiquer au client « Vous êtes ici ». Aussi, les valeurs maximales autorisées par l’implémentation devraient figurer dans ce même objet de réponse de pagination. Comme ça le client peut s’adapter et éviter de balancer des requêtes qui seraient rejetées. Ainsi, chaque implémentation peut poser ses conditions. 
Peut-être d’ailleurs que l’API GVA pourrait prévoir une méthode de négociation, qui retournerait une fois pour toutes ces valeurs de plages acceptées en fonction de la requête, et donner la possibilité de ne plus recevoir à nouveau ces valeurs en réponse paginée (pour éviter de recevoir un champ devenu inutile).
Yes !
Je préférerais que tu n’y touches pas, ce n’est pas ton rôle, à la place je devrais plutôt développer plus clairement l’API interne de Duniter de sorte que l’on puisse exploiter plus spécifiquement ce besoin. Ou alors que je développe cette base de donnée spécifique GVA. Et je crois que cette idée me séduit davantage.
Super si ça te va j’aimerais qu’on refasse une Cesium : tu reprends les droits de commit sur le dépôt et moi je peux intervenir en soutien. Donc tu fais ce que tu veux
J’aimerais quand même vraiment développer cette BDD dédiée à l’indexation, ça me semble être le moins invasif pour le code du cœur et le plus simple pour toi d’exploiter les données qui t’intéressent.
2 Likes
Oui tout a fait, ça correspond au bloc fonctionnel que j’ai nommé “client indexer” dans ma présentation des rml13, ce bloc fonctionnel doit évidemment avoir sa propre bdd, tout ça pour dire que j’ai pris la même décision coté Durs
2 Likes
Salut @cgeek,
J’espère que tu vas bien.
Je me demandais si on pouvais avancer sur un POC de BDD (ou API d’accès aux index) dédiée a GVA, d’ici les RML14 ?
Cela permettrait d’avoir un socle permettant d’implementer GVA dans Duniter, tout en développant Cesium2.
Si c’est pas possible, peut-on se planifier un créneau de travail commun en 2020 ? Césium est né en 2016, un refonte en 2020 me paraît bien
Merci a toi !
Bonjour,
pour info avec @jsprenger on commence à implémenter le schéma du module GVA de Dunitrust.
Dunitrust ne possède pas encore de module mempool et la librairie que l’on utilise ne gère pas encore les subscriptions. On va donc dans un premier se limiter aux query des données inscrites en blockchain.
5 Likes
Salut @ji_emme !
Ce qui serait chouette, c’est que je puisse faire interagir Cesium2 au fur et à mesure, sur un noeud ayant un début d’API GVA.
Cela permettrait de faire du pseudo-Scrumb, en restant focaliser sur les besoins réels et prioritaires des logiciels clients.
C’est aussi un moyen de rester motivé, car quand vous publier une nouvelle fonction, plusieurs personnes peuvent tester et juger des perf, du bon fonctionnement, etc.
Bref, est-ce que cela vous semble jouable d’avoir un cycle de développement interactif la dessus ?
2 Likes
Oui, c’est déjà le cas pour Dunitrust, je présente ça vendredi
Alors niveau perf on commence par une implémentation naïve donc pas optimisé, j’ai déjà plein d’idées d’optimisations mais que je mettrais en place dans un second temps.
De mon point de vue oui 
, reste a voir la dispo de @ji_emme et @jsprenger la dessus mais il ne sont pas seuls, je les accompagnent 
Je suis carrément motivé pour des cycle de développement interactif!
Les avantages que ça apportes sont en effet très nombreux.
2 Likes
Pour moi ça me va bien aussi. Itératif et interactif ça évitera de développer un peu à l’aveugle vis à vis des besoins des logiciels client.
2 Likes
Ah bon ? J’imagines que tu as du modifié Cs2 pour que ca marche, non ?
Je répondais à ça, je disais juste qu’il y a un début d’api gva, bien sur que je n’ai pas touché a Cs2 