Názory k článku Komunikace realizovaná úsporným binárním formátem MessagePack

Už je to delší dobu, co jsem zkoumal MessagePack pro moje interní používání - typicky pro komunikaci mezi procesy atd... A přišel mi příliš komplikovaný, takže jsem si nakonec vyvinul vlastní minimalistickou verzi přepisu JSONu do bináru

https://github.com/ondra-novak/imtjson/blob/master/docs/binjson_format.md

Jo asi nebude tak vychytaný, určitě tam není podpora změny endianu, cílem byla rychlá serializace a deserializace - komunikace mezi procesy na stejném stroji nebo mezi stroji na stejné platformě.

Vynalezl jsi kolo, bylo to nutné?

Asi ano, ale i to je nutný proces učení a seberozvoje. Jak psal, vyhovuje jeho potřebám více, tak proč ta jízlivost? Koneckonců, svět je plný úmyslně i neúmyslně znovu vynalezených kol i od mnoha známých firem. Tenhle argument já neberu :)

Pokud to kolo není hranaté, tak to není na škodu :) Opětovným vynalézáním kola je ostatně téměř každý studentský semestrální projekt. A člověk se učí zejména chybami. IMHO příkladný počin.

To nebyl argument, ale otázka.

Ale no tak. Víš co je to jízlivost?

Ta tvá "otázka" totiž obsahuje už i hodnocení.

To null a undefined je tam asi z důvodu komunikace přes JavaScript? Protože samotný JSON undefined nezná (a to je asi dobře :-).

Jinak ty komprimované klíče vypadají zajímavě, i když to asi komplikuje implementaci.

MessagePack je skvely format. V praxy som sa este nesteretol na to, ze by som narazil na jeho spominane obmedzenia.

Naopak zaraza ma, ze o nom vie tak malo ludi, lebo je vo vysledku mensi ako BSON, jednoduchsi ako CBOR, samopospisny narozdiel od Protobuff a sucasne ma viac moznosti.

Odporucam sa pozriet na jeho specifikaciu na messagepack.org, je kratka a prehladna.

Přesně tak, mě to oproti dalším "binárním JSONům" připadne jako prozatím nejlepší řešení. Ta omezení jsou skutečně většinou už mimo běžné oblasti použití (tedy mě osobně štve neexistence množin, ale to je spíš sémantický problém). Jinak je ten formát prakticky bezproblémový.

Proč množin? (nic proti, jen mě to fakt zajímá)

Ze sémantického důvodu. Třeba v našem případě, když se přenáší array/list, tak v 99% případů je to ve skutečnosti množina. Tj. jsou to prvky, které jsou unikátní (neexistují dva stejné prvky). Do JSONovského [seznamu] to ovšem jde nacpat, tuším, že ani schéma to moc neřeší. Jak říkám - jen sémantika, kdy by se například nějakýma závorkama ala Clojurovský #{} řeklo, že jde o množinu.

Protobuf IMHO patří do jiné kategorie "formátů" protože vyžaduje od všech komunikujících stran znát schéma. Kdežto JSON a jeho binární verze jsou flexibilnější a platíme za to tím, že se vlastně metainformace o struktuře pořád musí přenášet.

Zrovna dneska s tebou Pavle musim nesouhlasit a to hlavne s vetou staršího a dosti těžkopádného ASN.1.
Zrovna na ASN1 ja nedam dopustit a asi nebude tak tezkopadny a slozity, kdyz v nem bezi cele SSL/TLS, LDAP, je v nem ulozena cela PKI (certifikaty, klice, zpravy) a dokonce je na nem zalozeno i EMV a hromada dalsich TLV formatu :-)

CIsla i delky v nem muzou byt i vetsi jak 2⁶⁴, vicemene bez omezeni ....

A zrovna parser/composer ASN1 struktury je na par radek v C-cku - hlavne proto, ze je to prefixova notace :-)

A na rozdil od xml/json ma kanonicky tvar, takze pri podepisovani odpadavaji takove ty 'cachry' s tim, ze se musi odstranit vsechny bile znaky, aby ten podpis vysel na obou stranach stejne. A ty prevody z binarniho do hex/base64 v xml/json, aby ty data ten format pozral vubec pozral! Takze kdyz je tam trochu sifrovani a par podpisu, tak ten vysledny soubor timto pekelne bobtna.

Nejvice mne naopak fascinuje na zastancich techto novych/progre­sivnich xml/json a podobnych formatu, ta jejich mantra, ze v techto formatech to hned okem vsechno vidi narozdil od ASN1/TLV. Na to ja jim reknu, at se podivou na vystup ze serveru ktery nema ty vyznamove bile znaky a ze uvidi houby. A oni na to, ze to vlastne otviraji v prohlizeci ci jinem nastroji, a tedy s tim vlastne nikdy nepracuji primo. A to uz si klidne muzou vzit nejakou ASN1 ctecku ..... :-)

Zdravíčko. Já se na ASN.1 chystám (to jsem ale už sliboval že?). Mě se i ten formát líbí, akorát ta specka (resp. jich je víc - BER, DER, CER atd.) je strašně dlouhá v porovnání s třeba MsgPackem. Na druhou stranu toho umí ANS.1 o hodně víc.

PS: mě binární formáty nevadí, jsem na tom vyrostl :-) Je ale fajn je mít byte-based, aby se dal použít hexa prohlížeč/editor. No a příběhy o tom, jak si mezi službama posíláme obrovský JSONy, kde v několika kilobajtech dat je tak 20 bajtů informací, těch mám hodně...

Jo, jo, exemplarni pripad predavani par trivialni bajtu dat pres textovy format jsem videl nekdy kolem 2005(?) mezi iMac G3 (takove to pruhledne vajicko) a jejich cteckou cipovych karet.

Protokol byl neco ve zmyslu:
-> "Request data is: XX XX XX XX XX XX\n"
<- "Response status is: XX and data is: XX XX XX\n"

Kde to XX byly hexadecimalne uvedene ty binarni data co behaji na cipovou kartu a zpet .....

Tehdy jsem na to hledel s otevrenou pusou, jak si to nekdo vubec muze dovolit. Dneska v dobe JSON/XML a podobnych uz se nedivim nicemu :-)

20. 1. 2022, 16:36 editováno autorem komentáře

Neřekl bych, že TLS a PKI je důkazem toho, že by ASN.1 nebylo těžkopádné… Jinak ASN.1 samozřejmě má i nekanonické vyjádření, takže je na tom podobně, jako XML – v obou případech prostě musíte použít kanonické vyjádření, aby podepisování fungovalo. Rozdíl je snad jenom v tom, že v případě ASN.1 je kanonické vyjádření definované hned v základním standardu, kdežto u XML je to až ve standardu pro podepisování. Navíc nekanonické zápisy ASN.1 jsou podle mne omyl, který by ani neměl existovat.

Jinak pokud vám jde třeba jen o jeden údaj, ten najdete i v neformátovaném XML. V ASN.1 jedině tehdy, když točíte stále tu samou strukturu dokola a už víte, na který přesně bajt se máte koukat.