L'autre jour, je découvrais, via la dépêche sur neovim, un format « comme JSON mais rapide et petit » : MessagePack.
Sérialiser des données est le fait de coder des données depuis un format applicatif interne à un format utilisé pour les communiquer ou les stocker. De fait, on pourrait préférer sérialiser les données dans un format générique afin de les partager avec un maximum d'applications.
Une méthode qui marche bien pour sérialiser, c'est des séquences TLV, soit Type-Length-Value (ou Tag-Length-Value, c'est selon). L'idée est de mettre un type (ou tag), permettant d'indiquer quelle donnée nous aurons, ensuite sa longueur, afin d'indiquer l'espace nécessaire, puis la donnée.
Le premier avantage, évident, est la possibilité de sélectionner la méthode de traitement ainsi que réserver l'espace nécessaire avant de faire face à la donnée.
Le deuxième avantage est qu'il suffit de documenter, ou standardiser, les types de données afin d'obtenir un format d'échange suffisamment générique pour avoir des applications capables de représenter tous les types de données sans forcément savoir les interpréter.
Le troisième avantage est qu'on peut utiliser n'importe quelle représentation :
# Une version pseudo-binaire :
# TAG LENGTH VALUE
+--------+--------+---------+
| 0xA0 | 0x05 | HELLO |
+--------+--------+---------+
# Une version CSV :
STRING,5,HELLO
# Une version XML :
<string length="5">HELLO</string>
# Une version JSON :
{ string : { length: 5, value : "HELLO" } }
Avec MessagePack, nous avons une représentation binaire.
Là, mon application peut transmettre des messages entre ses différentes instances. Mais uniquement entre ses instances ; savoir qu'on a une chaîne de 5 caractères « HELLO » est inutile si on ne sait pas l'interpréter.
L'autre information qu'on trouve sur le site de MessagePack, c'est cette image :
Je comprends cette image comme « Ce qui est cool avec MessagePack, c'est l'absence de schémas » (je lis « "schema": 0 »).
{ "compact": true, "schema": 0}
Ce qui est faux et va être encore plus faux si je crois la section « Future discussion » de la spécification.
Faux car s'il n'y a pas de schéma explicite (sous-entendre « documenté »), le développeur va devoir coder et décoder un message selon un même schéma. Idem si deux applications doivent communiquer.
Encore plus faux car il semble que les développeurs de MessagePack discutent de la possibilité d'introduire des schémas (ou quelque chose de similaire).
En prenant ma machine à voyager dans le temps, j'ai fais un bond dans le passé pour déterrer le future de MessagePack : ASN.1.
D'accord, lire des normes (surtout ISO) c'est plus chiant que de les réinventer. Mais ASN.1 pour le schéma et un encodage BER (Basic Encoding Rules), on arrive à MessagePack avec schémas … et avec moins de limitations (oui avec BER on peut sortir du pur TLV si nos données sont trop longues), avec des cas déjà résolus (deux implémentations compatibles MessagePack pourraient très bien se comprendre sans donner exactement le même résultat à l'encodage ou au décodage. Dès que vous voulez signer vos données, c'est problématique … ASN.1 -> DER), avec des types de données franchement cool, possibilité d'étendre à l'infini (ou presque) et par application, …
Et si vous voulez juste sérialiser vos données sans schéma, faites man ber_printf et man ber_scanf. Vous êtes sur une système de type Microsoft Windows ? C'est aussi présent. Universellement disponible depuis longtemps.
Ce n'est pas le premier projet qui me fais me dire qu'il manque des cours d'histoire et culture générale de l'informatique dans les formations. Et je n'ai pas l'impression qu'historien spécialisé en informatique existe …
PS: Il n'y a rien de « comme JSON » dans MessagePack, c'est juste un schéma faisable avec MessagePack et BER … Ensuite :
BER
BerElement * Message = NULL;
Message = ber_alloc_t(0); /* ou LBER_USE_DER si on veut utiliser DER */
if(Message != NULL) {
ber_printf(Message, "{oboi}", "compact", 1, "schema", 0);
}
MessagePack (adapté d'un exemple de la documentation)
msgpack_sbuffer sbuf;
msgpack_packer pk;
/* msgpack::sbuffer is a simple buffer implementation. */
msgpack_sbuffer_init(&sbuf);
/* serialize values into the buffer using msgpack_sbuffer_write callback function. */
msgpack_packer_init(&pk, &sbuf, msgpack_sbuffer_write);
msgpack_pack_map(&pk, 2);
msgpack_pack_str(&pk, 7);
msgpack_pack_str_body(&pk, "compact", 7);
msgpack_pack_true(&pk);
msgpack_pack_str(&pk, 6);
msgpack_pack_str_body(&pk, "schema", 6);
msgpack_pack_int(&pk, 0);
# Un peu d'histoire
Posté par jacobus77 . Évalué à 6.
Si, si, ça existe, ça peut même faire pleurer Donald Knuth
[^] # Re: Un peu d'histoire
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Mais il a l'air passionnant cet article … Merci.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Mouais…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Franchement, je ne suis pas plus surpris que ça. Je veux dire, ça n'a rien de nouveau, des formats de sérialisation binaire, il y en a plein, avec par exemple le bencode de BitTorrent, le pickle de Python… Là, ça en fait un de plus, c'est tout. Et qui a l'air vraiment optimisé pour prendre peu de place.
En revanche, pour la comparaison avec BER, je ne suis pas d'accord. BER, c'est un truc de téléphoniste, et comme il se doit, c'est dans une spécification énorme, illisible et overkill. S'il existe un concurrent réellement comparable, il faut le chercher dans des normes faites par de vrais humains pour de vrais humains, des RFC quoi. Pas des tombereaux de paperasse de téléphonistes !
[^] # Re: Mouais…
Posté par Etienne Bagnoud (site web personnel) . É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
[^] # Re: Mouais…
Posté par icyfemur . Évalué à 2.
Et en plus c'est hype le BER, on peut le décoder en Javascript
[^] # Re: Mouais…
Posté par icyfemur . Évalué à 4.
J'ai eu à travailler sur cette RFC et celles liés, et ça n'a rien d'humain : CMS Advanced Electronic Signatures . Et l'encodage binaire utilisé, c'est du DER/BER de téléphoniste.
[^] # Re: Mouais…
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 24 avril 2015 à 18:37.
Oui, c'est tellement mieux un code source et démerde-toi (et si la RFC dit un truc mais que le code source n'est pas d'accord, ta RFC te dit qu'elle ne sert à rien en fait)
Pour de vrai humains? La section A.3 de la RFC 6716 devrait te plaire…
Les RFC, ce n'est pas (plus?) le bon exemple.
[^] # Re: Mouais…
Posté par Kalenx . Évalué à 4. Dernière modification le 25 avril 2015 à 05:27.
Généralisation abusive, rien de plus à dire… Sans même un effort pour la dissimuler, j'ai connu de meilleurs sophistes…
(À noter que je ne prétends pas que l'argument premier du fil était plus factuel…)
# Avro
Posté par MrBidon . Évalué à 1.
Un format qui a le vent en poupe actuellement. Son gros avantage est qu'il permet d'avoir une compatiblé possible entre différents schémas.
# Pas la première fois
Posté par Dinosaure (site web personnel) . Évalué à 10.
Ce n'est malheureusement pas la première fois où un retour dans le passé est souvent nécessaire pour se rendre compte du travail énorme qui a été fait jadis et réponds à des problématiques qu'on a toujours eu dans l'histoire informatique. Cela commence bien entendu par l'apparition d'un format révolutionnaire pour sérialiser les données en javascript parce que c'est hype jusqu'à des algorithmes ad-hoc révolutionnaires pour résoudre des problèmes qu'on connait déjà.
On voit au final pondre des projets sur Github qui sont des copies en moins bien faites de projets déjà existants dont leurs âges est souvent bien supérieurs à ces créateurs innovants full-stack. Si nous sommes dans une démarche de recherche et de curiosité à son propre compte, ré-implémenter la roue et de loin l'option la plus didactique pour un informaticien et découvrir sans avoir de limite de temps sur ce qu'on a fait, sur ce qui a été fait et sur ce qu'on nous dit de faire ne pose généralement aucun problème à tout le monde.
Mais le déterminisme de l'informatique ne s'applique pas à l'informaticien et les choix de certains informaticiens se rapprochent souvent plus de l'ignorance qu'à un travail de veille technologique qu'on nous présente sous toutes ses formes sur le fil d'actualité Linkedin. Car il est là le problème, et je m'en suis rendu compte par moi même et je le dénote malheureusement autour de moi, c'est le manque de recherche.
On m'a bien expliqué que dans un projet, avant de coder, avant que nos idées fusent sur le clavier à un débit tel que le moment où l'on réinvente le monde avec nos amis autour d'un verre (ce qui laisse place bien entendu à quelques idioties), il faut se renseigner, chercher l'existant, connaître les tenants et les aboutissants. Et ce travail de recherche malheureusement est de plus en plus délaissé par du code pure car il est, dans un cadre flexible qu'est une petite entreprise encore dans l'incubateur de l'agglomération, plus rentable de pondre du code vite que de se renseigner sur l'existant et d'apprendre à l'utiliser. Ce que veulent les gens, c'est que ça marche et le plus vite possible.
Bien entendu, dans un tout autre cadre d'une multinational brassant des millions de clients, le code vite n'a plus son intérêt et on en vient à s'intéresser à l'existant afin de voir si les problématiques de mise à l'échelle auquel nous devons faire face n'ont pas déjà été résolu. Et bien entendu, ces problématiques ont toutes une réponse qui dates des années 80 ou 90. Alors l'entreprise se tort en 4 pour essayer d'intégrer ces solutions dans leurs environnements. C'est là qu'intervient le retour dans le passé. Facebook en est la preuve existante car elle se soucie aujourd'hui de rendre son environnement correctement typé par le biais de Hack (pour PHP) ou de Flow (pour javascript) comme ci il s'agissait de réparer une erreur du passé qui ne date pourtant pas de si loin.
C'est ce que je regrette le plus dans le monde informatique jeune, c'est qu'on est rentré trop dans le hype, dans le jeune, dans cette période adolescente où tu ne manques pas de faire une crise à tes papas. Et puis arrive la maturité, et tu as intérêt à bien être préparé car ces papas ne te voient plus comme l'enfant prodige qui code vite mais comme un nouveau papa et là, ils ne feront pas de cadeau. Je comprends qu'on est plus intérêt à maîtriser parfaitement tout les outils qu'il y a autour de nous et la meilleur façon d'y parvenir, c'est de les coder soit même mais ne serait t'il pas plus sage de se laisser bercer par l'immense travail qui a déjà été fait et porter notre petite révolution au bout de cette édifice qu'on comparerait à la tour de Babylone ?
# BER me fait penser à OSC
Posté par lolop (site web personnel) . Évalué à 3. Dernière modification le 25 avril 2015 à 16:31.
OSC (Open Sound Control) est utilisé entre autre comme remplaçant à MIDI pour la communication entre ordinateurs / instruments.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Ben non, pas comme json
Posté par pasBill pasGates . Évalué à 1.
Un des gros avantages de json c'est que tu peux le streamer sans buffering. Ici, tu dois mettre le nombre d'éléments ou la taille en premier, cela oblige a faire un buffering de l'objet en entier avant de l'envoyer
[^] # Re: Ben non, pas comme json
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Non pas du tout, il y a la forme sans taille précisée (d'où ma remarque « avec moins de limitations (oui avec BER on peut sortir du pur TLV si nos données sont trop longues ») qui permet d'avoir une taille indéfinie avec un marqueur de fin.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# oui c'est vrai pourquoi ?
Posté par foudfou . Évalué à 3.
Salut Étienne, merci pour ce petit voyage dans le temps qui m'a permis d'approfondir ma connaissance de l'ASN1.
Je crois que l'ambition des formats comme BSON, JBSON, UJBSON, plus vaguement MessagePack, et CBOR c'est de sérialiser du JSON.
D'ailleurs SaltStack a choisi ce format sciemment on dirait:
Je suis étonné de voir autant de tentatives pour sérialiser du JSON, d'autant que certaines écartent sciemment l'ASN1 (cf. BJSON).
CBOR notamment argue que:
Du coup, pour sérialiser du JSON, tu choisirais vraiment ASN1/BER ?
[^] # Re: oui c'est vrai pourquoi ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Pas pour sérialiser du JSON … on ne sérialise pas un format, mais des données … et oui, pour échanger des données je préférerais utiliser un format qui me permet d'écrire un schéma, de le compiler pour l'intégrer dans mon code plutôt que de coder le schéma en "dur" dans mon application … comme ASN.1 est éprouvé (LDAP, SNMP, Kerberos, …) pour la création de schéma … après l'encodage va dépendre mais comme il existe BER/DER/CER/PER/ECN/XER/OER/GSER/… et ceux que je pourrais imaginer (si mes données sont à destination du Web, un truc genre JER (JSON Encoding Rules) … je suis pas le seul à penser ça utile)
Donc oui, ASN.1 est en haut de ma liste :D
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Du coté de Sereal
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Un format que je me dis qu'un jour, il faudrait que je teste : Sereal (https://metacpan.org/pod/Sereal). Voila un petit lien sur les performances du bousin https://github.com/Sereal/Sereal/wiki/Sereal-Comparison-Graphs.
# Interopérabilité
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
J'ai du rater un virage dans l'explication mais l'échange et le stockage sont deux problématiques bien distinctes. Dans le cas de l'échange inter-applicatif et en particulier B2B, l'interopérabilité ou la communicabilité des structures de datas est primordiale et le XML s'est imposé, ad hoc ou dans ses différentes déclinaisons comme le ebXML. Les "machins de téléphonistes" n'ont rien à faire dans la couche applicative …
[^] # Re: Interopérabilité
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Pas forcément. On peut très bien stocker des données sous forme de fichiers DER … les certificats X.501 par exemple.
L'important dans l'échange de données entre les applications, c'est d'avoir un schéma. Après, l'encodage, c'est juste une question de détails.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Encore un nouveau truc…
Posté par Anthony Jaguenaud . Évalué à 4. Dernière modification le 04 mai 2015 à 10:55.
…pour faire quelque chose qui existe depuis 1987 (première publication) et normalisé depuis 1995. Le XDR.
Ce qui est bien en informatique, c’est que les nouveaux croient découvrir de nouvelle problématique tous les jours alors qu’il y a déjà des solutions.
# Discussion sur Reddit à propos de ASN.1
Posté par jon . Évalué à 2.
Il y avait eu il y a quelques mois une discussion intéressante sur Reddit à propos de ce format, discussion qui se trouve ici
Les avis y semblent beaucoup plus partagés qu'ici…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.