Um Corbet zu zitieren (http://lwn.net/Articles/289067/): In other words, it's another XDR/RPC/pickle implementation, but tuned to Google's performance needs.
# Textual representation of a protocol buffer. # This is *not* the binary format used on the wire. person { name: "John Doe" email: "jdoe@example.com" }
--snip--
Hier nochmal der wichtige Teil: "This is *not* the binary format used on the wire". Diese Schreibweise ist nur symbolisch zur Erklärung gedacht.
Sprich: es geht ja gerade darum, dass dem Entwickler die interne Repräsentation herzlich egal sein kann und er nur über die generierte API auf die Datenstrukturen zugreift.
Google sagt ja auch, dass dies gegenüber XML ein Nachteil ist: protobuf hat keine "human readable" und selbstbeschreibende Notation.
Ah ok, Danke. Ich hatte das mit der Binärform zwar gelesen, mir war aber nicht klar, dass man sie nur über eine API zusammenstöpseln kann. Ich hatte gedacht, man könne zwischen Text- und Binärform hin und her konvertieren.
Kannst Du sicher, indem Du es (z.B. für C++) in einen stringstream synchronisieren lässt und Dir hinterher den Buffer ansiehst, bzw. den umgekehrten Weg zurück. Allerdings soll protobuf dem Entwickler ja gerade die Kodierung in jeglicher Form abnehmen und dabei so effizient wie möglich übertragen.
Vielleicht kann man ja (zu Debugging-Zwecken?) den Encoder auswechseln und durch eine XML generierende Engine ersetzen, wer weiß.
Ja, aber wesentlich langsamer in der Verarbeitung als diese Lösung hier, zumal die Googlelösung nicht nur das Datenformat festlegt, sondern auch den genauen Inhalt festlegt.
Beispiel für eine der Protodateien auf denen das System bassiert:
message Person { required int32 id = 1; required string name = 2; optional string email = 3; }
Mehr infos gibts hier: http://code.google.com/p/protobuf/
Wie kann man etwas in einer Programmiersprache "schön" lösen, wenn an der Sprache selbst überhaupt nichts "schön" ist? Operatorüberladung mag zwar in manchen Fällen auf den ersten Blick elegant erscheinen, aber sie stiftet häufig Verwirrung und bringt fehleranfälligen Code. IMHO eine gute Designentscheidung, komplett darauf zu verzichten (wie es auch Java macht).
>Effizienz in Entwicklung und Laufzeit hinsichtlich des jeweiligen Projektes reicht aus.
Ja, da stimme ich dir zu. Aber wo hilft dann eine Sprache, die so vor (fehleranfälligen und inkonsistent in den Compilern implementierten) Features strotzt, wie C++? Man braucht schon sehr viel Disziplin, um damit ordentlich und portabel zu programmieren (und im Team wird's noch schwieriger).
Operatorenüberladung bringt keinen fehleranfälligen Code und stiftet auch keine Verwirrung. Gerade weil es eine einheitliche Schnittstelle zum Serialisieren ist, operator<>() zu überladen, ist es eine flexible und vielfach unterstützte Methode, um verschiedenste Klassen zur I/O miteinander zu kombinieren.
Und was die generelle Operatorenüberladung angeht, so kann mir niemand erzählen, dass es ein Vorteil ist, die einfache mathematische Notation über Methodenaufrufe abzubilden.
num = 3 + 5;
sieht doch einfach nur elegant und einleuchtend aus und ist dank Operatorenüberladung auch noch völlig unabhängig davon, ob 'num' nun int, long, ein arbitrary precision Datentyp, eine eigene Klasse oder sonst etwas ist.
>sieht doch einfach nur elegant und einleuchtend aus
Es sieht so aus, ja. Aber was verbirgt sich dahinter? Was macht dieser Operator? Das kannst du in C++ nie mit Sicherheit sagen. Es ist eben ein Feature, was anfangs toll und elegant wirkt, aber doch interhältig sein kann. (Davon hat C++ noch viel mehr ;))
Also ich weis nicht was sich Google mit so Pille Plalle Scherze groß wichtig macht, was ist an dieser Serialisierung jetzt so anders als an anderen Serialisierungen? Ich seh da auch nicht groß den Vorteil gegenüber IDL, auch das hier ist viel komplizierter als z.B. Serialisierung zwischen .NET Applikationen.
Weder ist der Name von Google "cool" (Protocol Buffer, selbsterklärend, einfach, was ist dadran cool?) "cool" wäre es heißen würde Supermegaprotocol protoclprotocoldasselbstherrnDoodlegefälltweilersichdabei einenrunterholenkannundeinenganztollennamenund besonderscoolennamenhatabersonstnichtskannauserbuffern Und der Spruch von ihm war auch nicht "cool", du hast wirklich keine Ahnung
In other words, it's another XDR/RPC/pickle implementation, but tuned to Google's performance needs.
person {
name: "John \"Hunter\" Doe"
email: "jdoe@example.com"
}
Ist zwar im Moment noch nicht wichtig, aber so etwas finde ich immer interessant bei solchen Formaten.
--snip--
# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
name: "John Doe"
email: "jdoe@example.com"
}
--snip--
Hier nochmal der wichtige Teil: "This is *not* the binary format used on the wire". Diese Schreibweise ist nur symbolisch zur Erklärung gedacht.
Sprich: es geht ja gerade darum, dass dem Entwickler die interne Repräsentation herzlich egal sein kann und er nur über die generierte API auf die Datenstrukturen zugreift.
Google sagt ja auch, dass dies gegenüber XML ein Nachteil ist: protobuf hat keine "human readable" und selbstbeschreibende Notation.
Vielleicht kann man ja (zu Debugging-Zwecken?) den Encoder auswechseln und durch eine XML generierende Engine ersetzen, wer weiß.
lg
Erik
Beispiel für eine der Protodateien auf denen das System bassiert:
message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
}
Mehr infos gibts hier:
http://code.google.com/p/protobuf/
Aber es dürfte wenig überraschen das ein optimiertes Binärformat schneller zu parsen ist als ein relativ grobes Textformat
lg
Erik
Ja, da stimme ich dir zu.
Aber wo hilft dann eine Sprache, die so vor (fehleranfälligen und inkonsistent in den Compilern implementierten) Features strotzt, wie C++? Man braucht schon sehr viel Disziplin, um damit ordentlich und portabel zu programmieren (und im Team wird's noch schwieriger).
Und was die generelle Operatorenüberladung angeht, so kann mir niemand erzählen, dass es ein Vorteil ist, die einfache mathematische Notation über Methodenaufrufe abzubilden.
num = 3 + 5;
sieht doch einfach nur elegant und einleuchtend aus und ist dank Operatorenüberladung auch noch völlig unabhängig davon, ob 'num' nun int, long, ein arbitrary precision Datentyp, eine eigene Klasse oder sonst etwas ist.
lg
Erik
Ähm, ich meinte eigentlich operator<<() und operator>>().
lg
Erik
Es sieht so aus, ja. Aber was verbirgt sich dahinter? Was macht dieser Operator? Das kannst du in C++ nie mit Sicherheit sagen. Es ist eben ein Feature, was anfangs toll und elegant wirkt, aber doch interhältig sein kann. (Davon hat C++ noch viel mehr ;))
std::ostream &operator<<(std::ostream &o, MyClass &ob) lässt nun wirklich keine Fragen offen, was da wohin gestreamt wird.
lg
Erik
Protocol Buffers, Hauptsache nen coolen Namen.
"cool" wäre es heißen würde Supermegaprotocol
protoclprotocoldasselbstherrnDoodlegefälltweilersichdabei
einenrunterholenkannundeinenganztollennamenund
besonderscoolennamenhatabersonstnichtskannauserbuffern
Und der Spruch von ihm war auch nicht "cool", du hast wirklich keine Ahnung