MsGuru01 schrieb am 10.08.2019 15:28:
Linker schrieb am 10.08.2019 06:10:
Messagepack hat nichtmal das das "compacting" (encoding) von Zahlen, wie protobuf es hat. Und Protobuf selber ist auch simpel. Hast ein Header, Payload länge, dann den Payload dannach angehängt. Das ist ja noch einfacher als JSON zu tokenizen.
Und genau solche Unterschätzungen von Komplexität und Bug-Risiken sind es dann, über die Projekte immer wieder stolpern.
Kommt von Leuten, die von Softwareentwicklung nicht den allerleisten Schimmer haben, Technophobes Pack.
Just a few facts: JSON Specification = 16 Seiten, MessagePack = 9.
Du hast ja noch nie probiert so ein Format umzusetzen,
Falsch, auf absolut jeder Ebene – Zu meinen Erfahrungen gehören unter anderem auch diverse Implementierungen und eigene Spezifikationen diverser Formate und Protokolle, sowohl binärer als auch textueller.
du hast kein Schimmer.
Hättest Du gerne, ist aber nicht so.
Und jemand, der offensichtlich noch nicht mal das Heise-Kommentarformat fehlerfrei auf die Reihe bekommt, sollte vielleicht erst mal ein bißchen vorsichtiger über diese Dinge sprechen. B-)
(Mein Bugfix oben ist kostenlos.)
JSON besteht ja auch mehr aus als ", { }, Komma und [ ]. Escape Sequenzen und UTF-8, 16 und 32.
Der einzige Vorteil von JSON ggü. MessagePack, Flatbuffers oder Protobuf is, dass es menchenlesbar ist. Das wars aber auch.
Binäre Format spielen auf einer ganz anderen Ebene – manche Dinge sind dabei einfacher, andere dafür kritischer und insbesondere bei konsistenter systemübergreifender Nutzung kniffeliger und fehleranfälliger, wie sich schon oft in der Praxis gezeigt hat.
Daß JSON außerdem auch noch ziemlich gut menschenlesbar ist, ist ein Bonus obendrauf.
Hier ging es aber nun mal um textbasierte Formate, und da setzt sich JSON aus gutem Grund immer mehr durch, da es eben schon ziemlich minimalen Overhead hat, ganz im Gegensatz zu XML zum Beispiel.