@kimamila peut tu être plus précis sur le besoin stp ?
S’il s’agit d’avoir le solde du compte il suffit de récupérer toute les sources de la pubkey et de sommer leurs montants. Du coup je ne voit pas l’intérêt de ta proposition dans ce cas précis.
S’il s’agit de récupérer l’historique des transactions qui concernent un compte (entrantes comme sortantes), alors en effet rien ne le permet dans le schéma actuel. Dans ce cas on peut rajouter une requêtes movementsByAccount (pourquoi se limiter a une pubkey, ce n’est qu’un sous-ensemble des comptes possibles).
Avec comme inputs :
movementsByAccount(
paging: Paging!
# pubkey or script
account: String
state: DocumentState!
): Transactions
Ce qui retournerai le tableau des transactions concernant ce compte sur la période souhaitée (possible via l’input paging).
Concernant l’input account se pourrai être une clé publique ou un script de conditions plus complexes.
Cela répondrais t’il a t’on besoin ?
De mon coté je n’ai aps encore commencé l’implémentation de GVA a proprement parlé mais je commence a architecturer le projet pour avoir un module client indexer qui indexera les données que GVA (ou tout autre API client) devra être capable de retourner.
J’ai besoin d’avoir le schéma complet et définitif avant de commencer car en fonction du schéma la façon d’architecturer pour pouvoir répondre de façon optimisée ne sera pas la même.
De pl,s conformément a la roadmap de Durs présenté aux dernières RML, l’api client sera développée début 2020, ont a d’autres chantiers plus prioritaires avant dans le projet Durs.
La question n’est pas la. Plus tu déplace de l’intelligence coté serveur plus tu fragilise les serveurs et donc la monnaie. Tout ce qui peut être délégué aux clients doit l’être.
De plus, il peut y avoir d’autres formules pour calculer un soi-disant " temps proche de réel", les serveurs blockchain doivent être neutres et ne pas imposée une interprétation particulière du temps blockchain commun.
Cela dépend des utilisateurs finaux de chaque clients. Ce n’est pas aux serveurs blockchain d’'en décider.
Je suis d’accord pour faire mieux que BMA et fournir des données plus pratiques a exploiter, cependant il faut que j’en comprenne le besoin et la pertinence (comme pour l’historique des mouvements d’un compte pour lequel je t’ai fait une proposition).
Cependant je ne veut pas non plus que GVA devienne une usine a gaz déplaçant trop d’intelligence et de traitements coté serveurs blockchains, c’est dangereux et ça fragilise la monnaie.
De plus, les serveurs blockchain doivent autant que possible être neutre dans la façon d’interpréter les données. La formule de transformation du temps blockchain commun utilisée par Cesium ne me parle pas et n’est pour moi qu’une interprétation de se temps blockchain commun parmi d’autres.
De plus, c’est un traitement facile a faire coté clients.
Autant pour l’historique des mouvements d’un compte je comprend tout a fait après réflexion, autant pour le temps ça ne passe pas.
Prenons le temps d’en discuter point par point, de mesurer l’impact de chaque décision technique concernant cette API GVA. Le but c’est de faire ça bien sinon autant garder BMA.
Donc il faut prendre le temps d’expliciter chaque besoin et d’argumenter chaque solution proposée 