Cap’n Proto 1.0

• Das Opt-in-Verfahren für RPC-Cancellation wurde vom Aufruf context.allowCancellation() auf die Annotation allowCancellation im Schema umgestellt
• Nutzer, die context.allowCancellation() nicht verwenden, müssen beim Upgrade auf 1.0 nichts ändern; Cancellation bleibt standardmäßig weiterhin nicht erlaubt
• 1.0 ist ein Release mit Langzeitunterstützung (LTS); Bugfixes sollen langfristig in den 1.0-Branch zurückportiert werden
• Durch Leistungsverbesserungen bei Cap’n Proto RPC wurden die Speicherallokationen in der RPC-Implementierung und im KJ-I/O-Framework reduziert, einige RPC-Protokollnachrichten ausgelassen und durch verbessertes Buffering kleiner Nachrichten die Zahl der Syscalls verringert
• KJ verwendet unter macOS und BSD-Systemen kqueue() für asynchrone I/O-Verarbeitung; dies ersetzt den bisherigen, langsameren poll()-basierten Ansatz
• Die Implementierungen von KJ HTTP Client und Server unterstützen die Methode CONNECT
• capnp::RevocableServer wurde hinzugefügt und bietet eine Struktur, die hilft, Use-after-free-Bugs zu vermeiden, wenn ein Wrapper Objekte als RPC-Wrapper exportiert, deren Lifetime er nicht kontrolliert
• Die Entwicklung von 2.0 erfolgt im neuen v2-Branch; der master-Branch soll zum 1.0-LTS-Branch werden, damit bestehende Projekte nicht durch Änderungen unterbrochen werden
• Die Pläne für 2.0 betreffen keine abwärtsinkompatiblen Änderungen am Serialisierungsformat oder RPC-Protokoll, sondern Änderungen rund um die C++-API und KJ; Anwendungen in anderen Sprachen sind nicht betroffen
• Zu den Plänen für 2.0 gehören die Anforderung eines C++20- oder C++23-Compilers, die Nutzung von C++20-Coroutinen, die Einstellung der Unterstützung für deaktivierte Exceptions und den No-RTTI-Modus sowie Änderungen an den APIs von kj::Maybe und kj::AsyncOutputStream

[alstjr7375]

Oh … das ist endlich da.

[GN⁺]

Meinungen auf Hacker News

• Ich muss der Cap'n-Proto- und Sandstorm-Community eine sehr traurige Nachricht überbringen. Ian Denhardt (zenhack auf HN), der ein zentraler Contributor der Go-Implementierung war, ist vor einigen Wochen plötzlich verstorben. In den letzten drei Jahren haben wir viel zusammengearbeitet und sind Freunde geworden, daher ist das ein großer Verlust.
  Da ich nun faktisch als Projektlead Ians große Lücke füllen muss, brauchen wir dringend Hilfe, wenn ihr zum Projekt beitragen könnt. Wenn ihr Contributor oder Maintainer anderer Implementierungen wie C++, Rust usw. seid, würde ich sehr gern mit euch in Kontakt treten. Um Ians Arbeit fortzuführen, müssen wir mit sehr klugen Leuten zusammenarbeiten.
  RIP Ian, ich habe bei der Zusammenarbeit mit dir wirklich sehr viel gelernt. Kontakt: https://github.com/lthibault, https://matrix.to/#/#go-capnp:matrix.org, Telegram @lthibault, gmail louist87

  • Ich habe schon ein paar Mal erlebt, dass Menschen plötzlich gegangen sind, und es zerreißt einem wirklich die Seele. Jedes Mal erinnert es einen daran, wie zerbrechlich das Leben ist und wie schnell sich alles ändern kann.
    Ich blende die Zukunft nicht aus, aber ich versuche, die kleinen Dinge im Leben mehr zu genießen. Ian hat ein erstaunliches Vermächtnis hinterlassen, das viele Menschen erreicht hat. RIP Ian
  • Ich wusste nichts davon und bin schockiert. Ich mochte Ians Blog wirklich sehr; das ist so traurig.
  • @zenhack scheint auch die Haskell-Bindings gepflegt zu haben.
  • Ich kannte ihn nicht persönlich, aber ich habe seine Arbeit an Tempest, einem neueren Fork, der Sandstorm wiederbeleben sollte, sehr bewundert. Danke, dass du diese Nachricht geteilt hast.
  • Eine wirklich traurige Nachricht. Ian hat viele inspiriert, und sein Tod wird ein großer Verlust für die gesamte Community sein.

• Es ist überraschend, dass es neben Cap'n Proto so wenige Protokolle mit Promise Pipelining gibt. Das einzige andere Beispiel, das mir einfällt, ist 9p, aber 9p ist kein universelles Protokoll.
  https://capnproto.org/news/2013-12-13-promise-pipelining-cap...

  • Es ist zwar ein tolles Feature, aber im Vergleich zu einem Ansatz, bei dem Abfragen explizit gebündelt werden, dürfte es schwieriger sein, das Backend zu optimieren. Zum Beispiel kann ein maßgeschneiderter RPC-Aufruf, der in einer einzigen SQL-Abfrage endet, besser sein als mehrere separate, gepipelinete RPC-Aufrufe.
    Trotzdem wäre es ein Feature, das eigentlich weiter verbreitet sein könnte.
  • Pipelining ist keine gute Idee. Weil Objektinstanzen materialisiert werden, wird eine robuste Implementierung deutlich schwieriger. Es handelt sich nicht mehr um zustandslose Aufrufe, sondern um eine Struktur, bei der Funktionen auf bestimmten Objektinstanzen ausgeführt werden.
    Wenn zum Beispiel Client Joe Service A aufruft und das versprochene Ergebnis an Service B weitergibt, muss Service B einen Remote-Aufruf an Service A machen, um das Promise-Ergebnis zu erhalten.
    Dabei werden Sicherheitsgrenzen sofort kompliziert. Wie man das Delegationsmodell gestaltet, ist schon ein Problem; noch gravierender ist aber, dass Backpressure verschwindet. Wenn Client Joe Tausende Aufrufe an Service A erzeugt und die noch nicht materialisierten Ergebnisse an Service B weitergibt, kann Service A wie bei einem DDoS überflutet werden, sodass Service B in Timeouts läuft.
  • Mir war nicht klar, dass 9p Promise Pipelining hat. Genauer gesagt kann der Client File Descriptors auswählen, sodass er direkt nach dem Öffnen einer Datei eine Anfrage zum Lesen dieser Datei senden kann; schlägt das Öffnen fehl, scheitert auch das Lesen mit EBADF. Das ist elegant.
    Allerdings braucht Promise Pipelining auch Client-Unterstützung. Wenn ein Nutzer mehrere walks ausgibt, frage ich mich, ob es einen 9p-Client gibt, der sie alle sendet, ohne die Antwort auf den ersten walk abzuwarten.
    Außerdem bietet 9p Promise Pipelining nur für File Descriptors. Damit kann man schon viel machen, aber wenn man alle Dateien in einem Verzeichnis lesen möchte, müsste man ein read ausgeben und dann anhand des Ergebnisses dieses read ein walk machen können; 9p scheint das nicht zu unterstützen. In meiner Remote-System-Call-Protokollbibliothek rsyscall unterstütze ich genau das tatsächlich.
  • Als geistiger Vorfahre von Cap'n Proto gilt CapTP/VatTP, auch Pluribus genannt, das zusammen mit Mark Millers Sprache E entwickelt wurde. Als Wortspiel gibt es auch ein Konstrukt namens „unum“. Die tiefere Genealogie findet man in seiner Dissertation; dort kommen auch Barbara Liskovs Promise Pipelining und verwandte Ideen aus Argus, einer Erweiterung von CLU, vor.
    Ich meine mich zu erinnern, dass Mark Miller später auch den Promise-Vorschlag für JavaScript geschrieben hat. Die RPC-Erweiterung wurde allerdings nicht verwirklicht; stattdessen bekamen wir async/await, was nicht besonders gut zu Pipelining zu passen scheint.
    Spritely Goblins und OCapN, neuere Versuche, im Stil von E ein verteiltes Capability-System zu bauen, verfolgen ebenfalls Pipelining; wenn man also auf cap-talk ist, dürfte man noch ein paar ähnliche Protokolle genannt bekommen, auch wenn es wenige echte Use Cases gibt.
    So cool das Feature auch ist: Promise Pipelining scheint Programmierung mit echten, expliziten Promises zu erfordern, und wie knifflig das werden kann, ist ja bereits gut bekannt.
    Auf der Gegenseite, also bei Event Loops und kooperativ nebenläufigen „aktiven Objekten“, gibt es eine interessante und weniger bekannte Idee in DCOM/COM+: causality IDs. Sie dienen der Kontrolle von Reentrancy; siehe dazu CoGetCurrentLogicalThreadId in der Microsoft-Dokumentation und die Diskussion zu CALLTYPE_TOPLEVEL_CALLPENDING in Effective COM. Später hat man das offenbar in ASTA von Win8/UWP als neues Feature zu verkaufen versucht.
    [1] http://erights.org/elib/distrib/captp/index.html
    [2] http://erights.org/talks/thesis/index.html
    [3] https://spritely.institute/goblins/
    [4] https://github.com/ocapn/ocapn
    [5] https://groups.google.com/g/captalk/
    [6] https://learn.microsoft.com/openspecs/windows_protocols/ms-d...
    [7] https://learn.microsoft.com/windows/win32/api/combaseapi/nf-...
    [8] https://archive.org/details/effectivecom50wa00boxd/page/150
    [9] https://devblogs.microsoft.com/oldnewthing/20210224-00/?p=10...
  • Ich weiß nicht genau, wie Promise Pipelining in Cap'n Proto funktioniert, aber ich mache mir Gedanken über Fälle, in denen man ein Verzeichnis liest und für alle Einträge darin stat ausführt, oder in denen man nur einen von zwei Antwortwerten an den nächsten Aufruf weitergeben möchte.
    Letzteres scheint irgendwie machbar zu sein, Ersteres hängt jedoch von Dingen wie der Anzahl der Werte in der Ergebnisliste ab.

• Glückwunsch zum Release. Nach 10 Jahren muss das wirklich aufregend sein. Ich frage mich, ob künftig auch an Implementierungen in anderen Sprachen weitergearbeitet wird.
  Die Formatidee gefällt mir wirklich gut, aber die Hauptsprachen in unserem Stack werden nicht so unterstützt, dass ich sie in Produkten einsetzen würde.

  • Das ist tatsächlich die größte Schwäche von Cap'n Proto. Das Einzige, was ich wirklich ordentlich betreue, ist die C++-Implementierung; die anderen Implementierungen stammen von verschiedenen Beitragenden, daher variieren Reifegrad und Qualitätsniveau.
    Leider kann ich hier schwer etwas Neues versprechen. Die Arbeit an Cap'n Proto wird von den Bedürfnissen meines Hauptprojekts, der Cloudflare-Workers-Runtime, getrieben, und das ist überwiegend C++. Wir interagieren auch mit Go- und Rust-Services, und diese Implementierungen scheinen dort ihren Zweck zu erfüllen.
    Anders gesagt: Cap'n Proto ist ein Open-Source-Projekt, und ich hoffe, dass es Menschen nützt, aber es ist kein Produkt, das ich verkaufen will; deshalb liegt mein besonderer Fokus nicht darauf, alle zur Adoption zu bewegen. Wie immer sind Beiträge willkommen.
    Ein Fall, in dem es zu großen Veränderungen kommen könnte, wäre, wenn Cloudflare beschließt, Cap'n Proto zu einem öffentlichen Feature der Workers-Plattform zu machen. Dann gäbe es einen direkten Bedarf, es in mehreren Sprachen wirklich zu polieren. Das wird gelegentlich diskutiert, aber derzeit gibt es keine Pläne.
  • Es gab Leute, die die RPC-Schicht direkt schreiben wollten, statt einen Wrapper um die C++-Implementierung zu bauen, aber im Verhältnis zum direkten Nutzen müsste wirklich sehr viel Code neu geschrieben werden.
    Wenn du es versuchen möchtest, nur zu. Die Leute werden wahrscheinlich ziemlich kooperativ sein. Man sollte nur wissen, dass es schlicht sehr viel Arbeit ist.

• Als Hintergrund: Kenton hat Googles internes Proto-System jahrelang betrieben und nach seinem Weggang seine eigene Open-Source-Version gebaut.

  • Wahrscheinlich war er derjenige, der protobuf als Open Source veröffentlicht hat.

• Falls es bei Cloudflare jemanden gibt, der daran beteiligt war, Cap'n Proto statt etwas anderem wie protobuf auszuwählen, würde mich interessieren, welche Überlegungen dahinterstanden. Ich würde gern wissen, ob diese Gründe auch für mich relevant sind oder ob ich mir darüber keine Gedanken machen muss, solange ich nicht mit enormer Skalierung zu tun habe.

  • Es gibt einen Blogpost darüber, wie Cloudflare 2014 Cap'n Proto eingesetzt hat, drei Jahre bevor ich dazukam: https://blog.cloudflare.com/introducing-lua-capnproto-better...
    Auch heute basiert Cloudflares Datenpipeline – also das System, das am Edge Logs und Analytics erzeugt – größtenteils auf Cap'n-Proto-Serialisierung. An diesem Projekt war ich persönlich nicht stark beteiligt.
    Bei Cloudflare Workers habe ich das Projekt gestartet, also habe ich mein eigenes Ding verwendet. Das ist vermutlich nicht die Erklärung, die du suchst.
    Trotzdem denke ich, dass das RPC-Protokoll von Cap'n Proto deutlich ausdrucksstärker ist als die Alternativen und deshalb bei der Umsetzung des Sandboxings in der Workers Runtime sowie verteilter Systemfunktionen wie Durable Objects sehr geholfen hat. https://blog.cloudflare.com/introducing-workers-durable-obje...
  • Ich arbeite nicht bei Cloudflare, verfolge aber ihre Arbeit und habe gelegentlich mit performancekritischen Projekten zu tun. Ich würde vermuten, dass sie Cap'n Proto, flatbuffers, SBE usw. als eine andere Kategorie betrachtet haben als Datenformate wie Avro oder protobuf.
    Wenn man kein spaltenorientiertes Format wie Parquet möchte, sondern Daten eher in Record-Form, und ein Format will, bei dem die Vorab-Parsing-Zeit praktisch 0 ist, wird die Auswahlliste ziemlich kurz. Wenn man beim Lesen Feldwerte verändert, kann es natürlich zu Marshalling kommen.
    https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... behandelt diesen Trade-off.
    Cap'n Proto wurde ursprünglich für https://sandstorm.io/ entwickelt, und die Arbeit, die Kenton nach seiner Einstellung bei Cloudflare dort gemacht haben dürfte, führte letztlich zu Cloudflare Workers.
    Noch eine weitere Überlegung: https://github.com/google/flatbuffers/issues/2#issuecomment-...
  • Um die Situation zusammenzufassen, wie sie etwas mehr als ein Jahr nach meinem Einstieg war: Cloudflare baute eine Methode auf, um Logs vom Edge an eine zentrale Stelle zu senden, um Kunden-Analytics und Log-Bereitstellung für Enterprise-Kunden zu ermöglichen.
    Albert Strasheim, der zentrale Ingenieur, der das Ganze aufgebaut hat, hat die naheliegenden Serialisierungsoptionen gebenchmarkt, und nach meinem Verständnis zeigte sich, dass Cap'n Proto deutlich schneller als protobuf war.
    Es gab eine hervorragende C++-Implementierung, und sie konnte in nginx eingesetzt werden. Soweit ich mich erinnere, war auch etwas Lua beteiligt. Die Go-Implementierung auf der Konsumentenseite hatte ein paar raue Kanten, aber die benötigten Kernteile konnten die Leute beheben.
    Cloudflare hat schon immer großen Wert auf Kosteneffizienz bei Maschinen gelegt; angesichts der damaligen Performance-Anforderungen war es daher eine natürliche Wahl. Während meiner Zeit im Datenteam ließ sich mit Cap'n Proto ziemlich gut arbeiten, und auch das Teilen von Proto-Definitionen über ein zentrales Schema-Repository funktionierte gut.
  • Da der Lead-Entwickler von Cloudflare Workers der Schöpfer von Cap'n Proto ist, war die Wahl vermutlich leicht.

• Ich freue mich darauf, dass Cap'n Proto an der OCapN-Standardisierung mitarbeitet. Ich frage mich, ob das Teil der Arbeit an Cap'n Proto 2.0 sein wird.
  https://github.com/ocapn/ocapn

  • Leider ist Ian „zenhack“ Denhardt, der diese Beteiligung vorangetrieben hat, kürzlich unerwartet verstorben.
    Ich mag OCapN, aber ich habe derzeit viele andere Verpflichtungen und weiß nicht, wie viel Zeit ich persönlich investieren kann. Ich wünschte, ich könnte bessere Nachrichten überbringen, aber es ist ein tragischer Verlust für uns alle.

• Ich habe Cap'n Proto nie verwendet, bin kentonv aber dankbar für seine sehr informative FAQ-Antwort [1], die erklärt, warum Pflichtfelder in Protokollen problematisch sind.
  Ich verlinke sie oft, wenn Leute fragen, warum es in protobuf 3 keine required-Felder gibt.
  [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...

  • Eine wirklich wertvolle Perspektive. Auch ich hatte früher Schwierigkeiten zu verstehen, warum das so ist. Der Kern war, protobuf und Cap'n Proto nicht als In-Memory-Datenstrukturen zu verstehen, die die Welt aus Sicht eines einzelnen Prozesses in einer einzelnen Version abbilden, sondern als Serialisierungsformate, die über API-Grenzen hinweg mit unterschiedlichen Schemaversionen sowie Abwärts- und Aufwärtskompatibilität funktionieren müssen.
    Daher gilt das oft wiederholte Mantra „mache illegale Zustände nicht darstellbar“ hier nicht.
  • Typical bietet asymmetrische Felder, um Typevolution zu unterstützen:
    https://github.com/stepchowfun/typical#asymmetric-fields-can...
    Um Pflichtfelder sicher hinzufügen und entfernen zu können, bietet Typical mit asymmetric einen Zwischenzustand zwischen optionalen und Pflichtfeldern. Ein asymmetrisches Feld einer Struktur gilt beim Schreiben als Pflichtfeld, beim Lesen als optional. Anders als optionale Felder können asymmetrische Felder sicher zu Pflichtfeldern hochgestuft oder wieder zurückgestuft werden.
  • Wenn man diese Logik weiterführt, könnte man eigentlich auch zu dem Schluss kommen, praktisch alle statischen Typen abzuschaffen. Ehrlich gesagt ist das nicht völlig falsch, und es ist auch der Grund, warum Alan Kay objektorientierte Programmierung über dynamische Typisierung und Late Binding definiert hat. Wir bewegen uns aber in die entgegengesetzte Richtung und lernen dabei immer wieder dieselbe Lektion neu.
  • In der FAQ [1] heißt es: „Die richtige Antwort ist, dass die Anwendung bei Bedarf im Code auf Anwendungsebene validiert.“
    Statt sich auf Anwendungscode zu verlassen, wäre es schön gewesen, einen Parameter zu haben, mit dem man Pflichtnachrichten-Validierung ein- und ausschalten kann. Innerhalb einer Anwendung oder auf einem Message Bus könnte man sie ausschalten, aber im Allgemeinen wäre sie eingeschaltet eine große Hilfe für Entwickler.
    [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...
  • Im selben Zusammenhang gibt es noch eine weitere Falle: dass Dinge deserialisiert werden, die man gar nicht braucht, etwa wie bei generierten Clients.
    Was ich an Go-Interfaces wirklich mag, ist, dass ich nur das remote typisieren kann, was ich tatsächlich nutze, und den Rest überspringen kann. Es macht keinen Spaß, wenn ein Dienst wegen einer Vertragsänderung ausfällt, die er gar nicht verwendet; und solche Fehler sind schwer zu finden.

• Eine großartige Leistung. Ehrlich gesagt würde ich Cap'n Proto nicht empfehlen. Die C++-API ist sehr sperrig.
  Auch der Vorteil des Zero-Copy-Parsings ist kleiner als erwartet. Wegen der umständlichen Benutzbarkeit ist es unwahrscheinlich, dass man Daten dauerhaft in Cap'n-Proto-Datenstrukturen halten möchte, und in 99 % der Fälle kopiert man sie am Ende doch in die eigenen Datenstrukturen.
  Die Welt hat sich bei solchen binären Implementierungen weitgehend auf Protobuf eingependelt, daher gibt es auch mehr Reibung mit anderen Systemen.
  Ich habe es nur für Serialisierung verwendet. Die RPC-Seite könnte attraktiver sein.
  Ich hätte wirklich gerne gesehen, dass Thrift statt Protobuf/gRPC erfolgreich wird. Das Design war deutlich besser und flexibler als alles, was ich davor oder danach gesehen habe. Es scheint vor allem wegen der schlechten Dokumentation verschwunden zu sein; vermutlich spielte auch eine Rolle, dass kein großer Name dahinterstand.

  • Ich stimme zu, dass die für Zero-Copy nötige API besonders auf der Schreibseite etwas sperrig wird. Auf der Leseseite ist der Unterschied nicht groß. Andererseits ist Zero-Copy nur in bestimmten Szenarien, etwa zusammen mit mmap(), annähernd ein Paradigmenwechsel; bei Netzwerkkommunikation ändert sich ohne starke Techniken wie RDMA nicht viel.
    Für Anwendungsfälle, in denen Zero-Copy nicht so wichtig ist, wollte ich Cap'n Proto schon immer eine optionale alternative API hinzufügen, die „normale C-Structs“ oder etwas sehr Ähnliches verwendet und eine einmal kopierende Serialisierung wie protobuf anbietet, aber dazu bin ich bisher nicht gekommen.
    Persönlich hat mich allerdings das RPC-Protokoll immer deutlich mehr interessiert als die Serialisierung. Ich halte das RPC-Protokoll für fast jeden nichttrivialen Anwendungsfall für einen echten Paradigmenwechsel.
  • Ich glaube, du meinst flatbuffers, nicht protobuf. Das hat sich praktisch als Standard etabliert, und an einigen anderen Stellen wird SBE verwendet.
    Jedenfalls sind die Hauptprobleme binärer Serialisierung Schema- und Nachrichtenversionierung sowie Delta-Encoding. Wenn man diese beiden ignoriert, ist flache binäre Serialisierung trivial.
    Es gibt keine Library, die für beide Punkte eine gute Lösung bietet.
  • Wenn man kein Schema braucht, finde ich MessagePack ziemlich gut. Allerdings ist die JSON-Serialisierung von V8 ungewöhnlich schnell, sodass selbst MessagePack sie nur schwer schlägt; in anderen Sprachen ist es oft schneller und reduziert außerdem die Byte-Anzahl.
  • fbthrift ist immer noch sehr lebendig.

• Die Idee von capnp hat mir immer gefallen, aber am Ende ist es eben ein Message-Encoding-Protokoll, und es stört mich, dass es sogar eine Meinung dazu hat, wie ich meine Serverarchitektur aufbauen sollte.
  gRPC hat dieses Problem definitiv auch, ist aber sehr klar von protobuf getrennt, auch wenn protobuf einige gRPC-bezogene Funktionen hat.
  Wegen dieser Verflechtung tendiere ich im Vergleich zu capnp immer eher zu flatbuffers oder protobuf. Besonders, weil die Implementierungen von fb und pb deutlich einfacher sind und ich Einfachheit aus Sicht von Sicherheit und Wartbarkeit sehr hoch gewichte.
  Dass es an guten Drittanbieter-Implementierungen für Sprachen mangelt, sehe ich ebenfalls als direktes Signal dafür, dass diese Einschätzung richtig ist. Bus-Faktor und langfristige Überlebensfähigkeit sind ebenfalls sehr schlecht. Einfachheit gewinnt.

  • Das Problem, das ich bei jedem Anlauf mit cap'n'proto hatte, ist nicht nur, dass es eine Meinung zur Serverarchitektur hat, sondern dass es in C++ auch noch KJ mitbringt, eine sehr meinungsstarke Alternative zur STL. Als ich vor ein paar Jahren damit herumprobiert habe, griff es an vielen Stellen in die bestehende Codebasis hinein und war schwer zu handhaben.
    Auch die Rust-Version verlangt ihren eigenen normativen Lebensstil. Vieles davon ergibt in einer Zero-Copy-Welt Sinn, aber es machte trotzdem viele Ausdrucksformen schwierig, und auch die Dokumentation war schwer zu lesen.
    Schon allein aus diesem Grund wähle ich normalerweise flatbuffers.
    Trotzdem hoffe ich, dass irgendwann eine Situation kommt, in der cap'n'proto nötig und nützlich ist, und ich möchte zumindest eines der mehreren Hobbyprojekte fertigstellen, die ich über die Jahre geforkt habe, um es auszuprobieren. Hochwertiges Engineering steckt definitiv darin.
  • Mich würde interessieren, wie die Serialisierungsschicht die RPC-Wahl beeinflusst.

• Es ist zwar nicht neu, aber ich frage mich, ob der Name eine bewusste Hommage an Star Trek Voyager ist oder ob es eine andere Referenz gibt, die ich nicht kenne.
  https://memory-alpha.fandom.com/wiki/Captain_Proton

  • An diese Referenz habe ich tatsächlich nie gedacht.
    Der Name Cap'n Proto stand ursprünglich für Capabilities and Protobufs. Es war ein capabilities-basiertes RPC-Protokoll auf Basis von Protocol Buffers. Aber schon früh bekam ich Lust, ein völlig anderes Serialisierungsformat auszuprobieren. Trotzdem passte „Proto“ weiterhin im Sinne von Protokoll, also behielt ich den Namen bei.
    Das Wortspiel „cerealization protocol“ hat mir eigentlich jemand anderes erzählt, aber ich habe es sofort ins Logo aufgenommen.
  • Weil es als „cerealization protocol“ beworben wurde, dachte ich immer, es sei eine Anspielung auf das Frühstücksflockenprodukt Cap'n Crunch.

[bbulbum]

Es scheint um Serialization/RPC zu gehen, vermutlich ein Tippfehler.