Pour avoir lu le standard, c'est franchement très lisible et très propre. Après, le problème, c'est que c'est très précis afin de supprimer la moindre ambiguïté ce qui bien.
Ensuite, si tu veux aller dans l'optimiser à fond, tu as PER, qui est justement optimiser pour la transmission réseau.
Et finalement j'ai eu plus de difficulté à lire la spécification de MessagePack que celle de BER et ASN.1. Simplement parce que MessagePack a un premier octet, donc le tag ou type, qui est très mal défini, ton bit à la position X change de signification suivant le bit précédent. Avec BER, ça commence toujours par un octet :
8 7 6 5 4 3 2 1
+-------+-----+------------+
| Class | P/C | Tag number |
+-------+-----+------------+
Mais sérieux, lis les 13 pages de ISO/IEC 8825-1:2003, c'est tout l'encodage BER avec les types standards ... en 13 pages A4 c'est pas énorme, c'est très lisible et c'est pas du tout overkill.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mouais...
Posté par Etienne Bagnoud . En réponse au journal Retour vers le futur !. Évalué à 5.
Pour avoir lu le standard, c'est franchement très lisible et très propre. Après, le problème, c'est que c'est très précis afin de supprimer la moindre ambiguïté ce qui bien.
Ensuite, si tu veux aller dans l'optimiser à fond, tu as PER, qui est justement optimiser pour la transmission réseau.
Et finalement j'ai eu plus de difficulté à lire la spécification de MessagePack que celle de BER et ASN.1. Simplement parce que MessagePack a un premier octet, donc le tag ou type, qui est très mal défini, ton bit à la position X change de signification suivant le bit précédent. Avec BER, ça commence toujours par un octet :
Mais sérieux, lis les 13 pages de ISO/IEC 8825-1:2003, c'est tout l'encodage BER avec les types standards ... en 13 pages A4 c'est pas énorme, c'est très lisible et c'est pas du tout overkill.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell