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ě.
Naopak, složitost je dobrý argument. Právě proto třeba někdo preferuje Go před C++ nebo Javu nad Scalou.
Pokud myslel složitost používání API, úplně to chápu. Teď je otázka, zda práce vynaložená na implementaci nové knihovny (nemluvě o protokolu, se kterým cizí program prostě nespojíš, jelikož tam jsou věci jako ondra_common:: atd.), se vyplatí. Ale opět - neberu mu to!
Co s týče složitosti jazyků (když teda pominu, že bych osobně namísto Javy volil Kotlin a místo Go raději Python nebo Rust, pokud by šlo jenom o tyhle "lingvistické preference"), úplně rozumím - proti gustu... Akorát je pak zábavné, že OP přísahá zrovna na C++. ;-)
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.
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.
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 264, 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/progresivnich 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.