Historie
Das Verständnis, warum Protobuf erstellt wurde und welche Entscheidungen es im Laufe der Zeit verändert haben, kann Ihnen helfen, die Funktionen des Tools besser zu nutzen.
Warum haben Sie Protocol Buffers veröffentlicht?
Es gibt mehrere Gründe, warum wir Protocol Buffers veröffentlicht haben.
Protocol Buffers werden von vielen Projekten innerhalb von Google verwendet. Wir hatten andere Projekte, die wir als Open Source veröffentlichen wollten und die Protocol Buffers verwenden. Um dies zu tun, mussten wir zuerst Protocol Buffers veröffentlichen. Tatsächlich hatten Teile der Technologie bereits ihren Weg nach außen gefunden; wenn Sie den Code von Google AppEngine untersuchen, könnten Sie einige davon finden.
Wir wollten öffentliche APIs bereitstellen, die Protocol Buffers sowie XML akzeptieren, sowohl weil es effizienter ist als XML, als auch weil wir dieses XML ohnehin auf unserer Seite in Protocol Buffers umwandeln.
Wir dachten, dass Leute außerhalb von Google Protocol Buffers nützlich finden könnten. Protocol Buffers in eine Form zu bringen, mit der wir zufrieden waren, sie zu veröffentlichen, war ein unterhaltsames Nebenprojekt.
Warum ist die erste Release-Version 2? Was ist aus Version 1 geworden?
Die erste Version von Protocol Buffers („Proto1“) wurde Anfang 2001 entwickelt und entwickelte sich im Laufe vieler Jahre weiter, wobei neue Funktionen entstanden, wann immer jemand sie benötigte und bereit war, die Arbeit zu leisten, sie zu erstellen. Wie alles, was auf diese Weise erstellt wurde, war es ein ziemliches Durcheinander. Wir kamen zu dem Schluss, dass es nicht machbar war, den Code so zu veröffentlichen, wie er war.
Version 2 („Proto2“) war eine komplette Neufassung, obwohl sie die meisten Designideen und viele Implementierungsideen von Proto1 beibehielt. Einige Funktionen wurden hinzugefügt, einige entfernt. Am wichtigsten war jedoch, dass der Code bereinigt wurde und keine Abhängigkeiten von Google-Bibliotheken hatte, die noch nicht Open Source waren.
Warum der Name „Protocol Buffers“?
Der Name stammt aus den frühen Tagen des Formats, bevor wir den Protokollpuffer-Compiler hatten, um Klassen für uns zu generieren. Damals gab es eine Klasse namens ProtocolBuffer, die tatsächlich als Puffer für eine einzelne Methode diente. Benutzer fügten dieser Puffer einzeln Tag/Wert-Paare hinzu, indem sie Methoden wie AddValue(tag, value) aufriefen. Die Rohbytes wurden in einem Puffer gespeichert, der dann ausgegeben werden konnte, sobald die Nachricht erstellt worden war.
Seitdem hat der „Buffers“-Teil des Namens seine Bedeutung verloren, aber es ist immer noch der Name, den wir verwenden. Heute bezieht man sich mit dem Begriff „Protokollnachricht“ normalerweise auf eine Nachricht im abstrakten Sinne, mit „Protokollpuffer“ auf eine serialisierte Kopie einer Nachricht und mit „Protokollnachrichtenobjekt“ auf ein In-Memory-Objekt, das die geparste Nachricht repräsentiert.
Hat Google Patente auf Protocol Buffers?
Google hat derzeit keine erteilten Patente auf Protocol Buffers, und wir sind gerne bereit, Bedenken bezüglich Protocol Buffers und Patente auszuräumen, die Personen möglicherweise haben.
Wie unterscheiden sich Protocol Buffers von ASN.1, COM, CORBA und Thrift?
Wir denken, dass all diese Systeme Stärken und Schwächen haben. Google verlässt sich intern auf Protocol Buffers, und sie sind eine entscheidende Komponente unseres Erfolgs, aber das bedeutet nicht, dass sie die ideale Lösung für jedes Problem sind. Sie sollten jede Alternative im Kontext Ihres eigenen Projekts bewerten.
Es ist jedoch erwähnenswert, dass mehrere dieser Technologien sowohl ein Austauschformat als auch ein RPC-Protokoll (Remote Procedure Call) definieren. Protocol Buffers sind nur ein Austauschformat. Sie könnten leicht für RPC verwendet werden – und tatsächlich haben sie eine eingeschränkte Unterstützung für die Definition von RPC-Diensten –, aber sie sind nicht an eine einzige RPC-Implementierung oder ein einzelnes Protokoll gebunden.