Cap'n Proto 1.0

 (capnproto.org)
7 puan yazan GN⁺ 2023-07-29 | 3 yorum | WhatsApp'ta paylaş
  • RPC iptali için opt-in yöntemi, context.allowCancellation() çağrısından şemadaki allowCancellation annotation’ına değiştirildi
  • context.allowCancellation() kullanmayan kullanıcıların 1.0’a yükseltirken değişiklik yapması gerekmiyor; cancellation varsayılan olarak izin verilmeyen durumda kalmaya devam ediyor
  • 1.0, uzun süreli destek (LTS) niteliğinde bir sürüm; bugfix’lerin 1.0 branch’ine uzun vadede backport edilmesi planlanıyor
  • Cap’n Proto RPC performans iyileştirmeleri kapsamında RPC implementasyonu ve KJ I/O framework’ünde bellek ayırmaları azaltıldı, bazı RPC protocol message’ları atlandı ve küçük message buffering iyileştirilerek syscall sayısı azaltıldı
  • KJ, MacOS ve BSD türevlerinde asenkron I/O işlemleri için kqueue() kullanıyor; önceki daha yavaş poll() tabanlı yöntemden geçildi
  • KJ HTTP client ve server implementasyonları CONNECT method’unu destekliyor
  • capnp::RevocableServer eklendi; wrapper’ın lifetime’ını kontrol etmediği nesneleri RPC wrapper olarak export ederken use-after-free bug’larından kaçınmaya yardımcı olan bir yapı sunuyor
  • 2.0 geliştirmesi yeni v2 branch’inde yürütülecek; master branch’inin mevcut projelerin değişiklikler nedeniyle bozulmaması için 1.0 LTS branch’i olması planlanıyor
  • 2.0 planı, serialization format’ında veya RPC protocol’ünde geriye uyumsuz değişiklikler değil, C++ API’si ve KJ odaklı değişiklikler içeriyor; başka dillerde yazılmış uygulamalar etkilenmeyecek
  • 2.0 planında C++20 veya C++23 compiler gereksinimi, C++20 coroutine kullanımı, exception disabled ve no-RTTI mode desteğinin kaldırılması, kj::Maybe ve kj::AsyncOutputStream API değişiklikleri gibi başlıklar yer alıyor

İlgili okumalar

3 yorum

 
alstjr7375 2023-07-29

Oo.. bu sonunda geldi
 
GN⁺ 2023-07-29
Hacker News görüşleri

  • Cap'n Proto ve Sandstorm topluluklarına çok üzücü bir haber veriyorum. Go uygulamasının kilit katkıcılarından Ian Denhardt (HN'de zenhack) birkaç hafta önce aniden hayatını kaybetti; son 3 yılda birlikte çokça çalışıp arkadaş olduğumuz için büyük bir kayıp hissediyorum.
    Fiilen proje lideri olarak artık Ian'ın bıraktığı büyük boşluğu doldurmam gerekiyor; projeye katkıda bulunabilirseniz yardıma gerçekten çok ihtiyacımız var. C++, Rust vb. diğer uygulamaların katkıcıları veya bakımcılarıysanız mutlaka iletişime geçmek isterim. Ian'ın çalışmalarını sürdürebilmek için çok zeki insanlarla birlikte çalışmam gerekecek.
    Huzur içinde yat Ian; birlikte çalışırken senden gerçekten çok şey öğrendim. İletişim: https://github.com/lthibault, https://matrix.to/#/#go-capnp:matrix.org, Telegram @lthibault, gmail louist87

    • Ani kayıpları birkaç kez yaşadım; gerçekten insanın ruhunu çökerten bir şey. Böyle her olayda hayatın ne kadar kırılgan olduğunu ve her şeyin ne kadar hızlı değişebileceğini hatırlıyorum.
      Geleceği görmezden gelmiyorum ama hayatın küçük şeylerinden daha fazla keyif almaya çalışır oldum. Ian pek çok insana dokunan harika bir miras bıraktı. Huzur içinde yat Ian.
    • Bilmediğim bir haberdi, şoke oldum. Ian'ın blogunu gerçekten çok severdim; çok üzücü.
    • Görünüşe göre @zenhack Haskell binding'lerini de yönetiyordu.
    • Kendisiyle doğrudan tanışmıyordum, ama Sandstorm'u yeniden canlandırmaya yönelik yakın tarihli fork olan Tempest üzerindeki çalışmalarına büyük saygı duyuyordum. Bu haberi paylaştığın için teşekkürler.
    • Gerçekten çok üzücü bir haber. Ian birçok kişiye ilham verdi ve tüm topluluk için büyük bir kayıp olacak.

  • Cap'n Proto dışında promise pipelining özelliğine sahip protokollerin bu kadar az olması şaşırtıcı. Aklıma gelen başka tek örnek 9p; 9p ise genel amaçlı bir protokol değil
    https://capnproto.org/news/2013-12-13-promise-pipelining-cap...

    • Harika bir özellik olsa da, sorguları açıkça gruplama yöntemine kıyasla backend'i optimize etmek daha zor olacak gibi. Örneğin pipeline edilmiş birden çok ayrı RPC çağrısı yerine, tek bir SQL sorgusuyla sonuçlanan özel bir RPC çağrısı daha iyi olabilir
      Yine de daha yaygın kullanılmayı hak eden bir özellik
    • Pipelining iyi bir fikir değil. Nesne örneklerini somutlaştırdığı için sağlam bir implementasyonu çok daha zorlaştırıyor. Artık durumsuz çağrılar değil, belirli bir nesne örneği üzerinde fonksiyon çalıştıran bir yapı söz konusu
      Örneğin istemci Joe, Service A'yı çağırıp vaat edilen sonucu Service B'ye geçirirse, Service B'nin bu promise sonucunu almak için Service A'ya uzaktan çağrı yapması gerekir
      Bu noktada güvenlik sınırları hemen karmaşıklaşır. Yetkilendirme/devretme modelini nasıl kuracağınız da sorun, ama daha ciddi olan backpressure'ın ortadan kalkması. İstemci Joe, Service A'ya binlerce çağrı oluşturup henüz somutlaşmamış sonuçları Service B'ye geçirirse, Service A DDoS benzeri bir yükle karşılaşıp Service B'nin zaman aşımına düşmesine yol açabilir
    • 9p'de promise pipelining olduğunu bilmiyordum. Daha doğrusu istemci dosya tanıtıcısını seçebildiği için, bir dosyayı açar açmaz o dosyayı okuma isteği gönderebiliyor; açma başarısız olursa okuma da EBADF ile başarısız oluyor, bu yapı güzel
      Ancak promise pipelining istemci desteği de gerektirir. Kullanıcı birden çok walk gönderdiğinde, ilk walk yanıtını beklemeden hepsini gönderen bir 9p istemcisi var mı merak ediyorum
      Ayrıca 9p, promise pipelining'i yalnızca dosya tanıtıcıları için sunuyor. Sırf bununla bile çok şey yapılabilir, ama bir dizindeki tüm dosyaları okumak istiyorsanız read gönderip sonra o read'in sonucuyla walk yapabilmeniz gerekir; 9p bunu desteklemiyor gibi. Benim uzak sistem çağrısı protokolü kütüphanem rsyscall ise bunu gerçekten destekliyor
    • Cap'n Proto'nun manevi atası olarak, Mark Miller'ın E diliyle birlikte geliştirilen CapTP/VatTP, diğer adıyla Pluribus var. İsim oyunuyla “unum” adlı bir mekanizma da var. Daha derin soyağacı için onun tezine bakılabilir; burada Barbara Liskov'un promise pipelining'i ve CLU uzantısı Argus'taki ilgili fikirler de geçiyor
      Hatırladığım kadarıyla Mark Miller daha sonra JavaScript promise önerisini de yazdı. Ancak RPC uzantıları hayata geçmedi; bunun yerine pipelining ile pek uyumlu görünmeyen async/await'e sahip olduk
      E tarzında dağıtık bir yetki sistemi kurmaya yönelik daha yeni girişimler olan Spritely Goblins ve OCapN de pipelining'in peşinde; bu yüzden cap-talk'taysanız, gerçek kullanım örnekleri az olsa bile benzer birkaç protokol daha duyabilirsiniz
      Yine de harika bir özellik olsa da promise pipelining, gerçek ve açık promise'lerle programlamayı gerektiriyor gibi; bunun ne kadar çetrefilli hale gelebileceği zaten iyi biliniyor
      Karşı tarafta, yani event loop ve işbirlikçi eşzamanlı “aktif nesneler” tarafında ilginç ve daha az bilinen bir fikir olarak DCOM/COM+'ın causality IDs mekanizması var. Bu, yeniden girişliliği kontrol etmenin bir yolu; Microsoft belgelerindeki CoGetCurrentLogicalThreadId ve Effective COM'daki CALLTYPE_TOPLEVEL_CALLPENDING tartışmalarına bakılabilir. Daha sonra Win8/UWP'deki ASTA'da yeni bir özellikmiş gibi pazarlanmaya çalışılmış gibi görünüyor
      [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...
    • Cap'n Proto'nun promise pipelining'inin tam olarak nasıl çalıştığını bilmiyorum; ama bir dizini okuyup içindeki tüm öğelere stat uygulamak ya da iki yanıt değerinden yalnızca birini sonraki çağrıya geçirmek istediğiniz durumlar konusunda endişeliyim
      İkincisi bir şekilde mümkün gibi, ancak ilki sonuç listesindeki değer sayısı gibi şeylere bağlı

  • Çıkışı kutlarım. 10 yılın ardından gerçekten heyecan verici olmalı. Bundan sonra başka dil implementasyonları üzerinde de daha fazla çalışma olup olmayacağını merak ediyorum
    Format fikrini gerçekten çok seviyorum ama bizim stack’imizin ana dilleri, üründe kullanmak isteyeceğimiz kadar desteklenmiyor

    • Bu kısım gerçekten de Cap'n Proto’nun en büyük zayıflığı. Düzgün biçimde benim bakımını üstlendiğim tek şey C++ implementasyonu; diğer implementasyonlar ise çeşitli katkıcılardan geldiği için tamamlanmışlık ve kalite düzeyleri değişken
      Ne yazık ki burada yeni bir şey vaat etmem zor. Cap'n Proto üzerindeki çalışmalar, ana projem olan Cloudflare Workers runtime’ının ihtiyaçlarıyla yönleniyor ve bu da ağırlıklı olarak C++. Go ve Rust servisleriyle de etkileşime giriyor; ilgili implementasyonlar orada işlerini görüyor gibi görünüyor
      Başka bir deyişle Cap'n Proto bir açık kaynak projesi ve insanlara faydalı olmasını umuyorum; ancak satmaya çalıştığım bir ürün değil, bu yüzden herkesin benimsemesini sağlamaya özel olarak odaklanmıyorum. Her zamanki gibi katkılara açığız
      Büyük bir değişimin olabileceği durumlardan biri, Cloudflare’ın Cap'n Proto’yu Workers platformunun herkese açık bir özelliği yapmaya karar vermesi olurdu. O zaman birçok dilde gerçekten cilalanması için doğrudan bir ihtiyaç doğar. Zaman zaman bunu konuşuyoruz ama şu anda bir plan yok
    • C++ implementasyonunu saran bir wrapper yerine RPC katmanını doğrudan yazmak isteyenler olmuştu; ancak doğrudan kazanıma kıyasla yeniden yazılması gereken kod gerçekten çok fazla
      Denemek isterseniz deneyebilirsiniz. İnsanların oldukça işbirliğine açık olma ihtimali yüksek. Sadece işin çok fazla olduğunu bilmek gerekir

  • Biraz arka plan eklemek gerekirse, Kenton Google’ın kurum içi proto sistemini yıllarca işlettikten sonra ayrıldı ve kendi açık kaynak sürümünü yaptı

    • Muhtemelen protobuf’u açık kaynak olarak yayımlayan kişi de oydu

  • Cloudflare çalışanları arasında Cap'n Proto’yu protobuf gibi başka şeyler yerine seçme sürecine dahil olan biri varsa, hangi değerlendirmelerin yapıldığını merak ediyorum. Bu nedenlerin benim için de önemli olup olmadığını, yoksa muazzam ölçeklerle uğraşmıyorsam kafaya takmam gerekip gerekmediğini bilmek isterim

    • Cloudflare’ın 2014’te Cap'n Proto kullanımını ele alan bir blog yazısı var. Ben katılmadan 3 yıl önceydi: https://blog.cloudflare.com/introducing-lua-capnproto-better...
      Bugün de Cloudflare’ın veri pipeline’ı, yani edge’de log ve analitik üreten sistem, büyük ölçüde Cap'n Proto serileştirmesine dayanıyor. Ben o projeye kişisel olarak pek dahil olmadım
      Cloudflare Workers’a gelince, projeyi ben başlattığım için kendi şeyimi kullandım. Muhtemelen istediğiniz açıklama bu değildir
      Yine de Cap'n Proto’nun RPC protokolünün alternatiflerden çok daha ifade gücü yüksek olduğu için Workers Runtime’ın sandboxing implementasyonunda ve Durable Objects gibi dağıtık sistem özelliklerinin implementasyonunda çok yardımcı olduğunu düşünüyorum. https://blog.cloudflare.com/introducing-workers-durable-obje...
    • Cloudflare’da çalışmıyorum ama yaptıklarını takip ediyorum ve bazen performansa duyarlı projelerle uğraşıyorum. Tahminimce Cap'n Proto, flatbuffers, SBE gibi şeyleri Avro veya protobuf gibi diğer veri formatlarından ayrı bir kategori olarak görmüşlerdir
      Parquet gibi sütun odaklı değil de kayda daha yakın formda veri seçiyor ve ön ayrıştırma süresi fiilen 0 olan bir biçim istiyorsanız seçenekler oldukça azalıyor. Okurken alan değerlerini değiştirirseniz marshalling söz konusu olabilir
      https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... bu ödünleşimi ele alıyor
      Cap'n Proto aslında https://sandstorm.io/ için yapılmıştı; Kenton’ın Cloudflare’a alındıktan sonra yaptığı o çalışma da sonunda Cloudflare Workers’a uzanmış olmalı
      Bir başka değerlendirme noktası: https://github.com/google/flatbuffers/issues/2#issuecomment-...
    • Ben katıldıktan biraz fazla bir yıl sonraki durumu özetlemek gerekirse, Cloudflare edge’den merkezi bir noktaya log gönderip müşteri analitiği ve kurumsal müşterilere log sağlama yöntemini inşa ediyordu
      Bunun tamamını kuran kilit mühendis Albert Strasheim, güçlü serileştirme seçeneklerini benchmark etmişti; anladığım kadarıyla Cap'n Proto’nun protobuf’tan epey hızlı olduğu sonucuna varmıştı
      Harika bir C++ implementasyonu vardı ve nginx içinde kullanılabiliyordu. Hatırladığım kadarıyla biraz Lua da işin içindeydi. Tüketici tarafında kullanılan Go implementasyonunda pürüzlü yerler vardı ama gereken temel kısımları insanlar düzeltebiliyordu
      Cloudflare makine maliyeti verimliliğini her zaman önemsemiştir; bu yüzden o dönemdeki performans gereksinimleri düşünüldüğünde doğal bir seçimdi. Veri ekibindeyken Cap'n Proto ile çalışmak oldukça kolaydı ve merkezi şema deposundan proto tanımlarını paylaşma yöntemi de iyi işliyordu
    • Cloudflare Workers’ın baş geliştiricisi Cap'n Proto’nun yaratıcısı olduğu için seçim muhtemelen kolay olmuştur

  • Cap'n Proto’nun OCapN standardizasyonu çalışmalarına katılması beni heyecanlandırıyor. Bunun Cap'n Proto 2.0 çalışmalarının bir parçası olup olmayacağını merak ediyorum
    https://github.com/ocapn/ocapn

    • Ne yazık ki bu katılımı yürüten Ian “zenhack” Denhardt kısa süre önce beklenmedik şekilde hayatını kaybetti
      OCapN’i seviyorum ama şu anda üstlendiğim çok iş olduğu için kişisel olarak ne kadar zaman ayırabileceğimi bilmiyorum. Daha iyi haberler verebilmeyi isterdim ama bu hepimiz için trajik bir kayıp

  • Cap'n Proto'yu hiç kullanmadım ama protokolde zorunlu alanların neden sorun olduğunu açıklayan kentonv'nin çok yararlı FAQ yanıtı [1] için minnettarım
    İnsanlar protobuf 3'te neden required alan olmadığını her sorduğunda sık sık bağlantısını veriyorum
    [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...

    • Gerçekten değerli bir bakış açısı. Ben de eskiden bunun nedenini anlamakta zorlanıyordum. Kilit nokta, protobuf ve Cap'n Proto'yu, tek bir sürümdeki tek bir sürecin gördüğü dünyayı temsil eden bellek içi veri yapıları olarak değil, API sınırlarını aşan ve farklı şema sürümleriyle alt/üst uyumluluk içinde çalışması gereken serileştirme biçimleri olarak anlamaktı
      Dolayısıyla “geçersiz durumları temsil edilemez kıl” diye sıkça tekrarlanan mantra burada geçerli değil
    • Typical, tip evrimini kolaylaştırmak için asimetrik alanlar sunuyor:
      https://github.com/stepchowfun/typical#asymmetric-fields-can...
      Zorunlu alanları güvenle ekleyip kaldırabilmek için Typical, isteğe bağlı alanlarla zorunlu alanlar arasında bir ara durum olan asymmetric'i sunuyor. Bir struct'taki asymmetric alan, yazan taraf için zorunlu, okuyan taraf için isteğe bağlı kabul edilir. İsteğe bağlı alanların aksine, asymmetric alanlar güvenle zorunluya yükseltilebilir ya da tersine geri alınabilir
    • Bu mantığı genişletirsek, sonuçta neredeyse tüm statik tipleri ortadan kaldırma sonucuna da varılabilir gibi geliyor. Açıkçası tamamen yanlış da değil; Alan Kay'in nesne yönelimliliği dinamik tipler ve geç bağlama ile tanımlamasının nedeni de buydu. Ama biz bunun tersine gidip aynı dersi tekrar tekrar öğreniyoruz
    • FAQ'da [1] “doğru cevap, uygulamanın ihtiyaç duydukça uygulama düzeyi kodda doğrulama yapmasıdır” deniyor
      Uygulama koduna güvenmek yerine zorunlu mesaj doğrulamasını açıp kapatabilen bir parametre olsaydı iyi olurdu. Uygulama içinde veya mesaj veri yolunda kapatılabilir, ama genel olarak açık olduğunda geliştiriciye büyük yardım sağlar
      [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...
    • Aynı bağlamda bir tuzak daha var: üretilmiş istemciden alındığı gibi, ihtiyaç duymadığınız şeylerin bile deserialize edilmesi sorunu
      Go'nun arayüzlerinde gerçekten sevdiğim şey, yalnızca kullandığım kısmı uzaktan tiplendirip geri kalanını atlayabilmem. Bir servisin kullanmadığı sözleşme değişikliği yüzünden arızalanması hoş değil ve bulması da zor

  • Harika bir başarı. Dürüst olmak gerekirse Cap'n Proto'yu tavsiye etmezdim. C++ API'si oldukça hantal
    Sıfır kopyalı ayrıştırmanın faydası da beklediğimden daha küçük. Kullanımı hantal olduğu için veriyi Cap'n Proto veri yapıları içinde tutmak isteme olasılığınız düşük; %99 ihtimalle sonunda kendi veri yapılarınıza kopyalayacaksınız
    Bu tür ikili uygulamalarda dünya büyük ölçüde Protobuf üzerinde uzlaştığı için diğer sistemlerle sürtünme de daha fazla
    Ben yalnızca serileştirme amacıyla kullandım. RPC tarafı daha çekici olabilir
    Protobuf/gRPC yerine Thrift başarılı olsaydı gerçekten iyi olurdu. Öncesinde ya da sonrasında gördüğüm her şeyden çok daha iyi ve esnek tasarlanmıştı. Sanırım çoğunlukla berbat dokümantasyon yüzünden kayboldu; arkasında büyük bir ismin olmaması da muhtemelen bir nedendi

    • Sıfır kopya için gereken API'nin, özellikle yazma tarafında biraz hantal hale geldiğine katılıyorum. Okuma tarafı çok farklı değil. Öte yandan sıfır kopya, mmap() ile birlikte kullanım gibi belirli senaryolarda ancak bir paradigma değişimine yakın; ağ iletişiminde ise RDMA gibi güçlü teknikler kullanmadığınız sürece çok şeyi değiştirmiyor
      Sıfır kopyanın pek önemli olmadığı kullanım durumları için Cap'n Proto'ya “düz C struct'ları” ya da ona yakın bir biçim kullanan ve protobuf gibi bir kez kopyalayarak serileştirme yapan isteğe bağlı alternatif bir API eklemek hep istemiştim, ama henüz yapamadım
      Bununla birlikte kişisel olarak RPC protokolü tarafını serileştirmeden çok daha ilginç buldum. RPC protokolünün, önemsiz olmayan neredeyse her kullanım senaryosunda gerçek bir paradigma değişimi olduğunu düşünüyorum
    • protobuf değil, flatbuffers demek istiyorsunuz gibi. Fiilen standart haline geldi; bazı başka yerlerde de SBE kullanılıyor
      Her hâlükârda ikili serileştirmenin başlıca sorunu şema ve mesaj sürümleme ile delta kodlamadır. Bu ikisini görmezden gelirseniz düz ikili serileştirme basittir
      Yukarıdaki iki konuyu da iyi ele alan bir çözüm sunan kütüphane yok
    • Şemaya ihtiyacınız yoksa MessagePack bence oldukça iyi. Ancak V8'in JSON serileştirmesi anormal derecede hızlı olduğu için MessagePack'in onu yenmesi de zor; diğer dillerde çoğu zaman daha hızlıdır ve byte sayısını azaltır
    • fbthrift hâlâ gayet canlı

  • capnp'nin fikrini hep sevmişimdir; ama sonuçta bir mesaj kodlama protokolü olmasına rağmen sunucu mimarimi nasıl tasarlamam gerektiği konusunda da görüş sahibi olması beni rahatsız ediyor
    gRPC'de de kesinlikle böyle bir sorun var, ama protobuf'tan çok net biçimde ayrılmış durumda; protobuf'ta gRPC ile ilgili bazı özellikler olsa da
    Bu iç içelik yüzünden capnp ile her karşılaştırdığımda flatbuffers veya protobuf tarafına kayıyorum. Özellikle fb ve pb uygulamaları çok daha basit hale geldiği, güvenlik ve bakım açısından da basitliğe çok yüksek değer verdiğim için
    İyi üçüncü taraf dil uygulamalarının azlığını da bu yargının doğru olduğuna dair doğrudan bir işaret olarak görüyorum. Bus factor ve uzun vadeli yaşama şansı da çok kötü. Basitlik belirleyici oluyor

    • cap'n'proto'ya her yaklaştığımda yaşadığım sorun yalnızca sunucu mimarisi konusunda fikir dayatması değildi; C++'ta STL'ye oldukça görüşlü bir alternatif olan KJ'yi de beraberinde getirmesiydi. Birkaç yıl önce denediğimde mevcut kod tabanının her yerine uzanıp çalışmayı zorlaştırıyordu
      Rust sürümü de kendine özgü normatif bir yaşam tarzı gerektiriyor. Bunların çoğu sıfır kopya dünya görüşünde mantıklı, ama yine de birçok ifadeyi zorlaştırıyor ve dokümantasyonu da okumayı güçleştiriyordu
      Bu yüzden sırf bu nedenle bile genelde flatbuffers'ı seçiyorum
      Yine de bir gün cap'n'proto'nun gerekli ve faydalı olduğu bir durumla karşılaşmayı umuyor, yıllardır denemek için fork'ladığım çeşitli hobi projelerinden en az birini bitirmek istiyorum. İçinde yüksek kaliteli mühendislik olduğu kesin
    • Serileştirme katmanının RPC seçimini nasıl etkilediğini merak ediyorum

  • Yeni değil, ama adının Star Trek Voyager'a bilinçli bir saygı duruşu mu olduğunu, yoksa bilmediğim başka bir referans mı bulunduğunu merak ediyorum
    https://memory-alpha.fandom.com/wiki/Captain_Proton

    • Bu referansı aslında hiç düşünmemiştim
      Cap'n Proto adı aslında Capabilities and Protobufs anlamına geliyordu. Protocol Buffers tabanlı, yetenek tabanlı bir RPC protokolüydü. Ama erken dönemde tamamen farklı bir serileştirme biçimi denemek istedim. Yine de “Proto” protokol anlamında hâlâ uyduğu için adı korudum
      “cerealization protocol” kelime oyununu aslında bana başka biri söylemişti, ama hemen logoya ekledim
    • “cerealization protocol” diye tanıttıkları için, bunu her zaman Cap'n Crunch gevreğine bir gönderme sanmıştım
 
bbulbum 2023-07-30

Sanırım Serialization/RPC olmalı; muhtemelen bir yazım hatası var.