Je trouve ça pas malin de suffixer le nom du document de son numéro de version.
C’est appelé à évoluer, veut-on que ça fasse des liens morts à chaque évolution de version ?
2 Likes
A l’inverse, je prefererais avoir acces aux différentes version sans avoir à fouiller l’historique.
Ca permet de faire la distinction entre les typo et les vrai changement de version. et puis tu as besoin du protocol v10 sur l’interval [0…X[, du protocol v11 sur l’interval [X…Y[ , … Donc a mon sens, ya une utilité a avoir deux fichiers pour deux versions.
Par contre j’ai aucune confiance dans la centralisation des documents de specifications. il y a plus de richesse dans la diversité que dans l’unicité, il y a plus de coherence également à avoir une spec par implementation, chacun à sa maniere d’expliquer les choses, chacun fait des observation differentes, chacun nomme les variables comme il l’entends…
Un exemple concret: Cedric utilise la forme indexé des documents pour specifier la validation locale. C’est très bien, très clair et très cohérent avec la validation globale.
Mais je ne compte pas utiliser ce formalisme. Je trouverais ca absurde et reducteur de croire qu’il n’existe qu’une seule specification, c’est à contre pied de l’idée émancipatrice que nous portons. a minima celle que je souhaites porter.
Je vous prierais donc de ne pas y inscrire
mais bien d’y lister les vôtre si vous vous y sentez représenté.
1 Like
Les RFC 007 et 008 sont terminées pour moi, je les ai déplacées dans “Under discussion”, voir ma merge request.
1 Like
On peut dire que cette spec décrit le produit des implémentations (les blocs) et non les implémentations elles-mêmes, et qu’on n’est pas obligé d’implémenter directement l’algo donné dans le protocole mais qu’il faut être compatible avec cet algo ?
Je trouve aussi plus pratique de garder les différentes versions dans des fichiers différents, si on a besoin d’utiliser plusieurs versions en un même instant.
4 Likes
En principe t’as raison, mais heureusement que la spec actuelle ne s’arrete pas a cette definition sans quoi il m’aurait été très difficile de reproduire.
ex : compte le nombre d’occurences de (X)INDEX présent dans la spec, représentatif du mécanisme de validation interne et tu va vite comprendre que la spec décrit une implementation pas uniquement sont produit.
ex : pour décrire les documents, elois et moi utilisons des grammaires, formalisme qui, pour le coup, me semble plus précis même si au final ca change pas grand chose.
il y a beaucoup plus que les formats de données qui sont décrit, et même s’il faut être compatible, il existe une infinité de formalisme pour décrire tout cela. on pourrait très simplement, utiliser SQL (qui n’est pas très different de l’existant, d’ailleurs).
Faire le choix d’une spec unique, d’après moi cela reviens a croire que le concept est aboutit et qu’il n’y a plus besoin d’en changer, je crois, au contraire qu’il va evoluer et il serait dommage de se priver de la diversité des représentations qui permet une transmission des connaissances qui s’adapte aux differents êtres humains plutot que l’inverse.
1 Like
Sur ce point je suis d’accord avec @Junidev.
J’irai même plus loin, une fois approuvée, une RFC ne doit plus changée sauf correction de typo.
Par exemple pour le protocole DUBP v12 qui changera le mécanisme de destruction de la monnaie conformément a ce qui a été discuté sur ce fil, je vais proposer une nouvelle RFC protocole V12, se sera donc un document a part.
Tout a fait, de mon coté je rédigerai les spec du protocole Durs quand le logiciel sera mature, et mon approche sera également très différente.
Toutefois nous avons au moins 1 point commun irréductible : la monnaie G1. De mon coté je ressent le besoin que nous ayons un espace commun ou est consigné ce qui fait consensus et qui s’applique a toutes les implémentations de serveur blockchain faisant fonctionner la G1.
On peut réfléchir a refondre la rédaction du protocole DUBP dans ce dépot common de sorte a ne lister que des règles a respecter sans notion d’index 
Effectivement aujourd’hui la rédaction du protocole est trop proche de la façon dont c’est implémenté dans Duniter, c’est quelque chose que j’aimerais changer a l’avenir. Je ne me sentirai en capacité de le faire que lorsque j’aurais implémenté tout le protocole dans Durs (et que donc je le maîtriserai suffisamment pour le réécrire d’une façon plus agnostique de toute implémentation).
Si quelqu’un à l’envie et les compétences pour le faire, il peut soumettre une MR, sinon je finirai par le faire d’ici quelques mois/années
Meme remarque que @Junidev, aujourd’hui ce n’est pas le cas (pour des raisons historiques).
Cependant, il est bien entendu qu’on est pas obligé d’implémenter directement l’algo donné et qu’il faut juste être compatible, d’ailleurs Junidev et moi n’avons pas attendu votre avis pour prendre cette liberté 
On est d’accord en fait, au lieu d’une spec c’est juste un énoncé des règles de la G1 qu’il faudrait dans ce dépot common, une sorte de “contrat” que toute implémentation doit respectée, c’est sur que ça demande une réécriture complète
Oui, par contre lors d’une proposition d’évolution d’un protocole / d’une RFC il faudrait d’abord, sur la nouvelle branche, commiter une copie de l’ancienne version avec son nouveau nom, par exemple :
cp 0010_Duniter_Blockchain_Protocol_V11.md
0010_Duniter_Blockchain_Protocol_V12.md
Puis y commiter les modifications afin que l’on puisse bénéficier d’un diff directement dans la Merge Request au niveau du 2ème commit.
@elois, tu voudrais bien recréer une branche + MR de cette façon ?
Sinon en l’état, il n’est pas possible de visualiser directement les différences dans la MR ni les commenter via GitLab. Cela nous contraint à faire :
3 Likes
Voila qui est fait
1 Like
Duniter a déjà changé une fois de formalisme. Comme @tuxmain l’a dit, le protocole ne dit pas comment il faut implémenter mais que tout programme qui respecte le protocole est capable d’aboutir rigoureusement aux mêmes résultats, en l’occurrence produire les index du protocole.
L’ancien formalisme, c’était des phrases humaines. Les règles du protocole ne sont là que pour porter le sens, donc celui qui saisit le sens peut tout à fait aboutir aux mêmes résultas en empruntant un chemin différent. @Junidev et @elois vous l’avez d’ailleurs déjà fait, même Duniter l’a fait, certains algos ne sont pas implémentés tels qu’ils sont décrits.
Mais avec le formalisme actuel, il y a moins d’ambiguïtés que le langage humain. Si vous en trouvez un meilleur, tant mieux. Toutefois je ne sais pas si ça sera facile, car le formalisme actuel n’a d’autre but que d’aboutir à deux fichiers de contrôles particulièrement précieux :
- un fichier d’état de la monnaie à un instant t
- un fichier d’historique de toutes les opérations de la monnaie (le plus important !)
Être capable de produire ces deux fichiers est pour moi la condition sine qua non pour l’adoption d’un nouveau formalisme. Le 2. étant largement le plus important, car il permet de refléter la conformité du code relativement aux règles établies pour le processus d’interprétation d’un bloc. Dit autrement, le fichier 2. contient les variations d’état, ce qui est le cœur du protocole. Peu importe le formalisme, ce fichier doit pouvoir être établi.
3 Likes
je connais au moins un moyen de verifier la validité d’une transaction, de la wot… sans index .
il ya forcement équivalance avec ces fameux index mais je ne vois pas en quoi ce qui n’est ni document ni blockchain brut serait une condition sine qua non pour l’emplois d’un formalisme. Je pretend juste qu’il en existe d’autres qui ne devraient pas etre negligé au cas ou pour une raison ou une autre (que je ne connais pas) ces formalisme offres des solutions qui n’etaient pas auparavent existante.
par contre je n’en ai pas en tête qui me permette comme tu le fait de décrire à la fois la validation local et global, raison pour laquelle je ne suggère absolument pas d’en changer bien au contraire.
S’il y a équivalence alors tu es capable de reproduire ces fichiers. Si tu ne peux pas, c’est que ce formalisme ne respecte pas le protocole.
Or comme on souhaite que le protocole soit respecté (les règles de transformation d’un état vers un autre), c’est bien une condition sine qua non. C’est tout.
Dit autrement, changer de référentiel ne modifie pas l’objet (ici, les changements d’états).
1 Like
Je viens d’apprendre ce jour que le test dont je parle s’appelle du Golden Testing.
Les fichiers sont appelés golden files.
1 Like
on est d’accords, je manque de rigueur dans mon raisonnement ou dans mon expression. je sais pas trop.
en gros le but c’est que ca marche.
intéressant, moi j’ai une question cependant sur les tests, est-ce vraiment des tests (unitaire, golden ou ce que tu veux) si c’est toi qui les écris, ne faudrait-il pas qu’une autre personne les écrive pour valider l’idée !?
sur l’appli de mamie, ya pas de test
sur l’appli de bureautique classique, c’est le developpeur qui ecris les tests.
mais est-ce que vous rentreriez dans une fusée ou un Scanner d’hopital testé par les codeurs ?
1 Like
L’important c’est que les tests soient tous là, codés par qui ont veux. Il me semble que le 1er problème, c’est les trous dans le plan de test et donc les trucs non-testés.
Donc je dirai “Oui, si ils ont une méthode pour s’assurer qu’ils ont tout couvert”
me parait impossible, dans un temps raisonnable. je vois 2 raisons:
- l’expressivité d’un language est infini (les librairies sous jacente, peuvent avoir des problemes)
- les facteurs externe ne sont pas prévisible
on peut parler de maximiser la couverture et meme dans ce cas, je ne suis pas sur que les tests soient complets. par exemple si je test une addition peux-tu me dire avec certitude le nombre de cas qu’il faut tester ?
La couverture de tests mesure la quantité de code executé lors des test unitaires, pas les millions d’inputs possible à tester. c’est ce que je qualifierais de borne inférieur. pas de borne supérieur. la borne supérieur n’est pas facilement mesurable (voir pas du tout).
c’est pourquoi quand on programme le pilote automatique d’un avion, ce sont generalement des personnes differentes qui s’occupe de tester, pour éviter le biais evident du développeur qui à écrit la fonction.
je fais le chieur mais je n’ai pas, moi même, écris beaucoup de tests unitaires donc prenez pas ca de travers. c’est juste une suggestion pour les motivés avec un esprit rigoureux.
1 Like
La rédaction de tests n’est pas réservée aux développeurs. Mais cela ne les empêche pas d’en écrire non plus, les visions ne sont pas les mêmes et un développeur imaginera des cas que l’utilisateur ne pourra jamais imaginer pour la simple raison qu’il ignore les détails d’implémentation. Inversement, un utilisateur pourra imaginer des cas auxquels n’aurait pas pensé le développeur.
D’ailleurs si aujourd’hui Duniter tourne encore, c’est bien grâce aux tests que des développeurs ont rédigé. Donc, oui, ce sont bien des tests.
Cela dépend de la définition de “tout tester”. Si cela signifie « toute ligne de code doit avoir été exécutée par un test », ou encore « tous les cas de ce cahier de test doivent être passés avec succès », alors c’est possible.
Mais si c’est « couvrir tous les cas imaginables par un humain », alors effectivement c’est impossible en l’état des connaissances de l’humanité. Rien que pour les inputs de clés asymétriques possibles, il y en a bien de trop.
Tout cela est question de choix de définitions.
1 Like
je parlais pas d’utilisateurs, juste de testeurs. je faisais une opposition entre testeurs et developeurs
“code coverage” par definitions c’est 100% quand chaque ligne de code est executé au moins une fois, pour le coup, c’est pas ma definition c’est la definition admise par wikipedia et si on fouille les outils qui s’en charge alors tu y trouvera sans doute la meme chose.
j’ai, par le passé, travaillé dans un environnement ou les programmes sensible se testaient uniquement de cette manière, pour forcer au moins deux observateur à executer leur observation. puis il y avait les tests de non regression, puis la recette, … de nombreux outils d’integrations industriel integrent cela dans leur process.
le coeur du sujet, c’est de dire “le developpeur est sans doute le pire testeur de son code”, encore une fois c’est très bien de le faire. c’est mieux que de ne pas le faire (ma methode :p) et ca peux aider le developpement mais on fabrique pas un avion ou une centrale nucleaire de cette facon pour la raison ci-dessus!
j’en conclus une seule chose:
c’est un bon exercice lorsque des gens s’interessent, de suggérer d’écrire des tests.
1 Like
Pour moi il y a 2 types de tests :
-
Les tests boite blanche, dont la rédaction nécessiter de connaître comment fonctionne le dev derrière -> ne peut être fait que par un développeur
-
Les tests boite noire -> tests agnostiques de la façon dont fonctionne le dev derrière, tests donc purement fonctionnels. Peuvent être écris par des personnes qui n’ont pas développés la partie testée.
NB: rien a voir avec le découpage tests unitaires/tests d’intégration qui est une autre façon de découper les tests.
En effet je pense qu’avoir des tests boite noire écris par des gens qui n’ont pas développeur les serveurs blockchain serait très intéressant et nous ferai gagner en fiabilité 
Après faut il encore qu’il y ai des volontaires pour les concevoir puis les implémenter.
1 Like
C’est pas mal, mais les tests boîte noire ne sont pas sans intérêt même s’ils sont écrits par des devs. C’est juste que tu testes la fonction offerte par l’interface “boite noire”.
La plupart des tests automatisés actuels de Duniter sont de type boite noire.
J’aurais peut-être préféré que cette documentation reste encore dans le dépôt Duniter, car c’est actuellement la seule implémentation de DUNP et DUBP qui fait tourner la Ğ1.
Mais bon, faut bien à un moment se détacher et laisser les autres implémentations prendre la relève. Centraliser les RFC est aussi une bonne chose.
Faudra modifier deux dépôts pour une future évolution protocolaire et de l’implémentation de Duniter, mais comme peu d’entre elles sont prévus. Ça va.
Aller, assez de verbiages, c’est fusionné !
2 Likes