Fragen? Antworten! Siehe auch: Alternativlos
JSON ist halt für Leute denen XML zu komplex ist.Das bringt es ganz gut auf dem Punkt, finde ich.
XML ist für Leute denen ASN.1 zu komplex war.
Protobuf ist für Leute, denen JSON zu langsam ist
Wobei man das ja eigentlich noch erweitern müssten. Die Komplexität von XML hat ja die von ASN.1 übertroffen (es gibt eine ASN.1-Abbildung nach XML aber nicht umgekehrt).
Ich muss ja sagen, dass ich ein Freund von ASN.1 bin. Anfangs habe ich es für einen großen Mist gehalten, aber inzwischen habe ich meine Meinung geändert. Selbst der Schachtelungswahnsinn bei LDAP ist bei näherer Betrachtung verteidigbar.
Aber so im Vergleich zu ASN.1/DER hat Protocol Buffers irgendwie nur Nachteile. Besonders ärgerlich weil vermeidbar finde ich, dass sie am Anfang nicht die Länge mitschicken. Wenn man schon seine Daten serialisieren muss, dann will man doch wenigstens einen Zero-Copy-Decoder haben. Das heißt, ich will auf einen gesendeten String zugreifen, ohne den rauskopieren zu müssen. Und Zero-Copy heißt halt auch, dass man am Anfang weiß, wie groß die Nachricht werden wird. Denn sonst muss man lesen, was kommt, und immer mehr Speicher dazu allozieren und umkopieren, was wir ja gerade vermeiden wollten. Wenn ich das richtig sehe gerade, dann hat Protocol Buffers keine Längenübertragung am Anfang. Und keinen Ende-Marker. Wenn ich also zwei Protocol Buffers hintereinander übertragen will, weil ich im Protokoll Pipelining unterstützen will, dann gibt das einen Konflikt mit der Erweiterbarkeit. Hey, ASN.1/DER hat seit den 80ern Pipelining und Erweiterbarkeit drin. Wie arm ist DAS denn, sowas dann wegen "not invented here" wegzuschmeißen und neu zu machen und dann schlechter als das Original zu sein. Die sollten sich alle mal was schämen.
Aber das Tooling ist so toll!1!! Ja, äh, und? Du bist ein fucking Coder. Code dir halt dein Tooling selbst. WTF? Seit wann ist diese "wische mir doch mal bitte jemand den Arsch ab"-Mentalität eigentlich gesellschaftlich akzeptabel geworden?