Cap'n Proto 1.0

 (capnproto.org)
7 पॉइंट द्वारा GN⁺ 2023-07-29 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • RPC cancellation की opt-in विधि context.allowCancellation() call से बदलकर schema के allowCancellation annotation पर शिफ्ट कर दी गई है
  • जिन users ने context.allowCancellation() का उपयोग नहीं किया है, उन्हें 1.0 upgrade के समय कोई बदलाव करने की जरूरत नहीं है, और cancellation default रूप से अभी भी allowed नहीं है
  • 1.0 एक long-term support (LTS) प्रकृति की release है, और 1.0 branch में bugfixes को लंबे समय तक backport करने की योजना है
  • Cap’n Proto RPC performance सुधारों में RPC implementation और KJ I/O framework में memory allocation घटाना, कुछ RPC protocol messages को छोड़ना, और छोटे message buffering में सुधार के जरिए syscalls कम करना शामिल है
  • KJ अब MacOS और BSD परिवार में asynchronous I/O handling के लिए kqueue() का उपयोग करता है, जो पहले के धीमे poll()-based तरीके से बदलाव है
  • KJ HTTP client और server implementation अब CONNECT method को support करते हैं
  • capnp::RevocableServer जोड़ा गया है, जो ऐसे objects को RPC wrapper के रूप में export करते समय use-after-free bugs से बचने में मदद करने वाली संरचना देता है जिनकी lifetime wrapper control नहीं करता
  • 2.0 development नए v2 branch पर आगे बढ़ेगा, और योजना है कि master branch 1.0 LTS branch बने ताकि existing projects बदलावों से break न हों
  • 2.0 की योजना serialization format या RPC protocol में backward-incompatible बदलावों की नहीं है, बल्कि C++ API और KJ-केंद्रित बदलावों की है; अन्य भाषाओं में लिखी applications प्रभावित नहीं होंगी
  • 2.0 की योजना में C++20 या C++23 compiler requirement, C++20 coroutine का उपयोग, exception disabled और no-RTTI mode support बंद करना, kj::Maybe और kj::AsyncOutputStream API बदलाव आदि शामिल हैं

संबंधित पढ़ाई

3 टिप्पणियां

 
alstjr7375 2023-07-29

ओह.. यह आखिरकार आ ही गया
 
GN⁺ 2023-07-29
Hacker News की रायें

  • Cap'n Proto और Sandstorm कम्युनिटी के लिए एक बेहद दुखद खबर साझा कर रहा हूँ। Go implementation के मुख्य contributors में से एक Ian Denhardt (HN पर zenhack) का कुछ हफ्ते पहले अचानक निधन हो गया। पिछले 3 सालों में हमने साथ बहुत काम किया था और दोस्त बन गए थे, इसलिए यह बहुत बड़ा नुकसान महसूस हो रहा है
    अब project lead के रूप में मुझे Ian की बड़ी कमी पूरी करनी होगी, इसलिए अगर आप project में योगदान दे सकते हैं तो मदद की बहुत ज़रूरत है। अगर आप C++, Rust आदि दूसरी implementations के contributor या maintainer हैं, तो मैं आपसे ज़रूर संपर्क करना चाहूँगा। Ian के काम को आगे बढ़ाने के लिए बहुत होशियार लोगों के साथ काम करना होगा
    RIP Ian, तुम्हारे साथ काम करते हुए मैंने सचमुच बहुत कुछ सीखा। संपर्क: https://github.com/lthibault, https://matrix.to/#/#go-capnp:matrix.org, Telegram @lthibault, gmail louist87

    • मैंने कुछ बार ऐसे लोगों को अचानक जाते देखा है, और यह सचमुच आत्मा को तोड़ देने वाला अनुभव होता है। जब भी ऐसा होता है, यह याद दिलाता है कि ज़िंदगी कितनी नाज़ुक है, और सब कुछ कितनी जल्दी बदल सकता है
      मैं भविष्य से मुँह नहीं मोड़ता, लेकिन ज़िंदगी की छोटी-छोटी चीज़ों का ज़्यादा आनंद लेने की कोशिश करने लगा हूँ। Ian ने एक अद्भुत विरासत छोड़ी है, जिसने बहुत से लोगों को छुआ। RIP Ian
    • यह खबर मुझे नहीं पता थी, सुनकर सदमा लगा। मुझे Ian का blog बहुत पसंद था, बेहद दुखद
    • लगता है @zenhack Haskell bindings भी maintain करते थे
    • मैं उन्हें व्यक्तिगत रूप से नहीं जानता था, लेकिन Sandstorm को फिर से जीवित करने की उनकी हालिया fork Tempest पर किए काम का बहुत सम्मान करता था। यह खबर बताने के लिए धन्यवाद
    • सचमुच बहुत दुखद खबर है। Ian ने कई लोगों को प्रेरित किया, और यह पूरी community के लिए बड़ा नुकसान होगा

  • Cap'n Proto के अलावा promise pipelining वाले protocols इतने कम हैं, यह हैरान करने वाला है। दिमाग में आने वाला दूसरा उदाहरण सिर्फ 9p है, लेकिन 9p कोई general-purpose protocol नहीं है
    https://capnproto.org/news/2013-12-13-promise-pipelining-cap...

    • यह एक बढ़िया feature तो है, लेकिन explicit तरीके से queries को batch करने की तुलना में backend को optimize करना मुश्किल लगता है। उदाहरण के लिए, pipelined कई अलग-अलग RPC calls की जगह, एक custom RPC call बेहतर हो सकती है जो एक single SQL query में पूरी हो जाए
      फिर भी यह ऐसा feature है जो ज्यादा व्यापक रूप से इस्तेमाल हो सकता था
    • Pipelining अच्छा idea नहीं है। यह object instances को materialize करता है, इसलिए robust implementation कहीं ज्यादा कठिन हो जाती है। अब यह stateless calls नहीं रहता, बल्कि किसी खास object instance पर function चलाने वाली संरचना बन जाता है
      उदाहरण के लिए, client Joe Service A को call करता है और उसके promised result को Service B को pass कर देता है, तो Service B को उस promise result को पाने के लिए Service A पर remote call करना पड़ेगा
      इस समय security boundaries तुरंत complex हो जाती हैं। delegation model कैसे होगा यह भी समस्या है, लेकिन उससे भी गंभीर बात यह है कि backpressure खत्म हो जाता है। अगर client Joe Service A पर हजारों calls बना दे और अभी materialize न हुए results को Service B को pass कर दे, तो Service A DDoS की तरह flood हो सकता है और Service B timeout हो सकता है
    • मुझे नहीं पता था कि 9p में promise pipelining है। ज्यादा सही कहें तो client file descriptor चुन सकता है, इसलिए file खोलते ही उस file को read करने की request भेज सकता है, और अगर open fail हो जाए तो read भी EBADF के साथ fail हो जाता है—यह structure अच्छा है
      हालांकि promise pipelining के लिए client support भी चाहिए। अगर user कई walk issue करे, तो क्या कोई 9p client है जो पहले walk response का इंतजार किए बिना सब भेज देता हो, यह जानना चाहूंगा
      साथ ही 9p सिर्फ file descriptors के लिए promise pipelining देता है। सिर्फ इससे भी बहुत कुछ किया जा सकता है, लेकिन अगर directory की सभी files पढ़नी हों, तो read issue करने के बाद उस read result के आधार पर walk कर पाना चाहिए, और लगता है 9p इसे support नहीं करता। मेरी remote system call protocol library rsyscall में यह सच में support है
    • Cap'n Proto के आध्यात्मिक पूर्वज के रूप में Mark Miller की E language के साथ विकसित CapTP/VatTP, यानी Pluribus, मौजूद है। नामों के खेल में “unum” नाम की device भी है। और गहरी lineage के लिए उनके papers देखे जा सकते हैं; इनमें Barbara Liskov की promise pipelining और CLU extension Argus से जुड़े ideas भी आते हैं
      मुझे याद है कि Mark Miller ने बाद में JavaScript promises proposal भी लिखा था। हालांकि RPC extension साकार नहीं हुआ, और उसके बजाय हमें async/await मिला, जो pipelining के साथ बहुत मेल खाता नहीं दिखता
      E के तरीके से distributed authority system बनाने की ज्यादा हालिया कोशिशें, Spritely Goblins और OCapN, भी pipelining को pursue करती हैं, इसलिए cap-talk में हों तो real use cases भले कम हों, कुछ और मिलते-जुलते protocols के बारे में सुनने को मिल सकता है
      हालांकि feature शानदार है, promise pipelining के लिए शायद असली explicit promises के साथ programming करनी पड़ती है, और यह कितना tricky हो सकता है यह पहले से अच्छी तरह पता है
      दूसरी तरफ, यानी event loop और cooperative concurrent “active objects” की तरफ, एक दिलचस्प और कम-ज्ञात idea DCOM/COM+ के causality IDs हैं। यह reentrancy को control करने का साधन है; Microsoft docs में CoGetCurrentLogicalThreadId और Effective COM में CALLTYPE_TOPLEVEL_CALLPENDING पर चर्चा देखें। बाद में शायद Win8/UWP के ASTA में इसे नए feature की तरह बेचने की कोशिश की गई थी
      [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 की promise pipelining ठीक-ठीक कैसे काम करती है, लेकिन directory पढ़कर उसके अंदर की सभी entries पर stat लगाना हो, या response values में से सिर्फ एक को अगली call में pass करना हो, तो चिंता होती है
      दूसरी स्थिति किसी तरह संभव लगती है, लेकिन पहली result list में values की संख्या वगैरह पर निर्भर करती है

  • रिलीज़ के लिए बधाई। 10 साल बाद आया है, तो वाकई काफी उत्साहजनक लग रहा होगा। आगे दूसरी भाषाओं के implementations पर भी और काम होगा या नहीं, यह जानने की उत्सुकता है
    फॉर्मैट का आइडिया मुझे सच में बहुत पसंद है, लेकिन हमारे stack की मुख्य भाषाओं को इतना support नहीं मिलता कि हम उन्हें product में इस्तेमाल करना चाहें

    • असल में यही हिस्सा Cap'n Proto की सबसे बड़ी कमजोरी है। मैं ठीक से केवल C++ implementation को maintain करता हूं, और बाकी implementations अलग-अलग contributors से आते हैं, इसलिए उनकी completeness और quality का स्तर अलग-अलग है
      अफसोस है, लेकिन यहां कुछ नया promise करना मुश्किल है। Cap'n Proto पर काम मेरे मुख्य project, Cloudflare Workers runtime, की जरूरतों से चलता है, और वह मुख्य रूप से C++ है। यह Go और Rust services के साथ भी interact करता है, और वे implementations वहां अपना काम करती दिखती हैं
      दूसरे शब्दों में, Cap'n Proto एक open source project है और मैं चाहता हूं कि यह लोगों के लिए उपयोगी हो, लेकिन यह कोई product नहीं है जिसे मैं बेचने की कोशिश कर रहा हूं, इसलिए इसे सभी से adopt करवाने पर कोई खास focus नहीं है। हमेशा की तरह, contributions का स्वागत है
      एक स्थिति में बड़ा बदलाव हो सकता है: अगर Cloudflare यह तय करे कि Cap'n Proto को Workers platform की public feature बनाया जाए। तब कई भाषाओं में इसे सच में polish करने की सीधी जरूरत पैदा होगी। इस पर कभी-कभी चर्चा होती है, लेकिन फिलहाल कोई योजना नहीं है
    • कुछ लोग C++ implementation के ऊपर wrapper बनाने के बजाय RPC layer को सीधे लिखना चाहते थे, लेकिन सीधे फायदे की तुलना में फिर से लिखना पड़ने वाला code बहुत ज्यादा है
      अगर आजमाना चाहें तो कर सकते हैं। लोग शायद काफी सहयोगी होंगे। बस यह जान लें कि काम बहुत ज्यादा है

  • थोड़ा background जोड़ूं तो, Kenton ने Google का internal proto system कई साल तक चलाया, फिर छोड़ने के बाद अपना open source version बनाया

    • शायद वही व्यक्ति था जिसने protobuf को open source किया था

  • अगर Cloudflare में कोई कर्मचारी Cap'n Proto को protobuf जैसी दूसरी चीजों के बजाय चुनने में शामिल रहा हो, तो मैं जानना चाहूंगा कि किन बातों पर विचार किया गया था। मैं समझना चाहता हूं कि क्या वे कारण मेरे लिए भी महत्वपूर्ण हैं, या फिर जब तक मैं बहुत बड़े scale से deal नहीं कर रहा, उन्हें ignore कर सकता हूं

    • 2014 में Cloudflare द्वारा Cap'n Proto के इस्तेमाल पर एक blog post है। यह मेरे join करने से 3 साल पहले की है: https://blog.cloudflare.com/introducing-lua-capnproto-better...
      आज भी Cloudflare की data pipeline, यानी edge पर logs और analytics बनाने वाला system, काफी हद तक Cap'n Proto serialization पर आधारित है। मैं personally उस project में ज्यादा शामिल नहीं था
      Cloudflare Workers के मामले में, मैंने project शुरू किया था, इसलिए मैंने अपनी चीज इस्तेमाल की। शायद यह वह explanation नहीं है जो आप चाहते हैं
      फिर भी, मुझे लगता है कि Cap'n Proto का RPC protocol alternatives की तुलना में कहीं ज्यादा expressive है, जिससे Workers Runtime के sandboxing implementation और Durable Objects जैसी distributed system features को implement करने में बहुत मदद मिली। https://blog.cloudflare.com/introducing-workers-durable-obje...
    • मैं Cloudflare में काम नहीं करता, लेकिन उनके काम को follow करता हूं और कभी-कभी performance-sensitive projects संभालता हूं। मेरा अनुमान है कि Cap'n Proto, flatbuffers, SBE आदि को Avro या protobuf जैसे दूसरे data formats से अलग category में देखा गया होगा
      अगर आप Parquet जैसे column-oriented format के बजाय record जैसी data shape चुनते हैं, और ऐसा format चाहते हैं जिसमें upfront parsing time लगभग 0 हो, तो options काफी कम रह जाते हैं। पढ़ते समय field values बदलें तो marshaling हो सकती है
      https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... में इस trade-off पर बात की गई है
      Cap'n Proto मूल रूप से https://sandstorm.io/ के लिए बनाया गया था, और Kenton ने Cloudflare में hire होने के बाद जो काम किया होगा, वह आखिरकार Cloudflare Workers तक पहुंचा होगा
      एक और consideration: https://github.com/google/flatbuffers/issues/2#issuecomment-...
    • मेरे join करने के एक साल से थोड़ा ज्यादा समय बाद की स्थिति का सार यह था कि Cloudflare edge से central point तक logs भेजने का तरीका बना रहा था, ताकि customer analytics और enterprise customers के लिए logs उपलब्ध कराए जा सकें
      मेरी समझ के मुताबिक, इस पूरे system को बनाने वाले मुख्य engineer Albert Strasheim ने प्रमुख serialization options को benchmark किया था, और पाया था कि Cap'n Proto protobuf से काफी तेज है
      इसका एक बेहतरीन C++ implementation था, और इसे nginx में इस्तेमाल किया जा सकता था। जहां तक याद है, थोड़ा Lua भी शामिल था। Consumer side पर इस्तेमाल हो रहे Go implementation में rough edges थे, लेकिन जरूरी core हिस्सों को लोग ठीक कर पाए
      Cloudflare ने हमेशा machine cost efficiency को महत्व दिया है, इसलिए उस समय की performance requirements को देखते हुए यह स्वाभाविक choice थी। Data team में रहते हुए Cap'n Proto के साथ काम करना काफी आसान था, और central schema repository में proto definitions share करने का तरीका भी अच्छे से काम करता था
    • संभव है कि choice आसान रही हो, क्योंकि Cloudflare Workers का lead developer Cap'n Proto का creator है

  • Cap'n Proto का OCapN standardization work में हिस्सा लेना देखकर उत्साह है। सोच रहा हूं कि क्या यह Cap'n Proto 2.0 work का हिस्सा बनेगा
    https://github.com/ocapn/ocapn

    • दुर्भाग्य से, इस participation को lead कर रहे Ian “zenhack” Denhardt का हाल ही में अचानक निधन हो गया
      मुझे OCapN पसंद है, लेकिन अभी मेरे पास इतने सारे काम हैं कि personally कितना समय दे पाऊंगा, पता नहीं। काश मैं बेहतर खबर दे पाता, लेकिन यह हम सभी के लिए दुखद क्षति है

  • मैंने Cap'n Proto इस्तेमाल नहीं किया है, लेकिन protocol में required fields समस्या क्यों बनते हैं, यह समझाने वाले kentonv के बेहद उपयोगी FAQ जवाब [1] के लिए आभारी हूँ
    जब भी लोग पूछते हैं कि protobuf 3 में required fields क्यों नहीं हैं, तो मैं अक्सर इसे link करता हूँ
    [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...

    • यह वाकई मूल्यवान दृष्टिकोण है। पहले मुझे भी समझना मुश्किल लगता था कि ऐसा क्यों है। मुख्य बात protobuf और Cap'n Proto को किसी single version के single process द्वारा देखी जाने वाली दुनिया को दर्शाने वाले in-memory data structures की तरह नहीं, बल्कि API boundary के पार अलग-अलग schema versions और backward/forward compatibility के साथ काम करने वाले serialization formats की तरह समझना था
      इसलिए “illegal states को unrepresentable बनाओ” वाला व्यापक रूप से दोहराया जाने वाला mantra यहाँ लागू नहीं होता
    • Typical, type evolution में मदद के लिए asymmetric fields देता है:
      https://github.com/stepchowfun/typical#asymmetric-fields-can...
      required fields को सुरक्षित रूप से जोड़ने और हटाने के लिए, Typical optional और required fields के बीच की intermediate state, asymmetric, उपलब्ध कराता है। किसी struct का asymmetric field लिखने वाले के लिए required और पढ़ने वाले के लिए optional माना जाता है। optional fields के विपरीत, asymmetric fields को सुरक्षित रूप से required में promote किया जा सकता है या वापस उलटा किया जा सकता है
    • इस logic को आगे बढ़ाएँ तो क्या यह निष्कर्ष भी नहीं निकल सकता कि मूलतः सभी static types हटा दिए जाएँ? सच कहूँ तो यह पूरी तरह गलत भी नहीं है, और यही वजह है कि Alan Kay ने object-orientation को dynamic typing और late binding से define किया था। लेकिन हम उसके उलट दिशा में जाते हुए वही सबक बार-बार सीखते रहते हैं
    • FAQ [1] में लिखा है कि “सही जवाब यह है कि application अपनी जरूरत के अनुसार application-level code में validate करे”
      application code पर निर्भर रहने के बजाय, काश कोई parameter होता जिससे required message validation को on/off किया जा सके। application के अंदर या message bus में इसे बंद किया जा सकता है, लेकिन आम तौर पर on होने पर यह developers के लिए काफी मददगार होता
      [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...
    • इसी संदर्भ में एक और trap है। generated client से मिलने वाली चीज़ों की तरह, जिन चीज़ों की जरूरत नहीं है वे भी deserialize हो जाती हैं
      Go के interfaces में मुझे सच में जो बात पसंद है, वह यह है कि मैं केवल वही remotely type कर सकता हूँ जो इस्तेमाल करता हूँ और बाकी को skip कर सकता हूँ। service जिन contract changes का इस्तेमाल भी नहीं करती, उनके कारण outage होना न मजेदार है, न ढूँढना आसान

  • शानदार उपलब्धि है। ईमानदारी से कहूँ तो मैं Cap'n Proto recommend नहीं करूँगा। C++ API बहुत अटपटा है
    zero-copy parsing का लाभ भी उम्मीद से कम है। usability अटपटी होने के कारण संभावना कम है कि आप data को लगातार Cap'n Proto data structures में रखना चाहेंगे, और 99% मामलों में अंततः अपने data structures में copy करेंगे
    इस तरह के binary implementation के लिए दुनिया काफी हद तक Protobuf पर settle हो चुकी है, इसलिए दूसरे systems के साथ friction भी अधिक है
    मैंने इसे केवल serialization के लिए इस्तेमाल किया है। RPC side शायद अधिक आकर्षक हो सकती है
    काश Protobuf/gRPC के बजाय Thrift सफल हुआ होता। उससे पहले या बाद में मैंने जो भी देखा, उससे इसका design कहीं बेहतर और flexible था। लगता है यह मुख्यतः खराब documentation के कारण गायब हुआ, और शायद पीछे कोई बड़ा नाम न होना भी वजह रही होगी

    • मैं सहमत हूँ कि zero-copy के लिए जरूरी API, खासकर write side पर, कुछ अटपटा हो जाता है। read side बहुत अलग नहीं है। वहीं zero-copy केवल कुछ खास scenarios में, जैसे mmap() के साथ इस्तेमाल करने पर, paradigm shift जैसा है; network communication में, RDMA जैसी मजबूत technique इस्तेमाल न हो तो बहुत बड़ा बदलाव नहीं आता
      जिन use cases में zero-copy बहुत महत्वपूर्ण नहीं है, उनके लिए मैं हमेशा Cap'n Proto में “plain C structs” या उसके करीब किसी रूप का इस्तेमाल करने वाला, और protobuf की तरह एक-copy serialization देने वाला optional alternative API जोड़ना चाहता था, लेकिन अभी तक कर नहीं पाया
      हालांकि व्यक्तिगत रूप से मुझे serialization की तुलना में RPC protocol में कहीं अधिक रुचि रही है। मुझे लगता है RPC protocol लगभग हर non-trivial use case में वास्तविक paradigm shift है
    • लगता है आप protobuf नहीं, flatbuffers की बात कर रहे हैं। वह वास्तव में standard बन चुका है, और कुछ अन्य जगहों पर SBE इस्तेमाल होता है
      खैर, binary serialization की मुख्य समस्या schema और message versioning, और delta encoding है। इन दोनों को ignore कर दें तो flat binary serialization trivial है
      ऐसी कोई library नहीं है जो ऊपर की दोनों चीज़ों को अच्छी तरह handle करने वाला समाधान दे
    • अगर schema की जरूरत नहीं है तो MessagePack मुझे काफी अच्छा लगता है। हालांकि V8 का JSON serialization असामान्य रूप से तेज है, इसलिए MessagePack के लिए भी उसे हराना मुश्किल है; अन्य भाषाओं में यह अक्सर तेज होता है और bytes की संख्या घटाता है
    • fbthrift अभी भी अच्छी तरह जिंदा है

  • capnp का आइडिया मुझे हमेशा पसंद आया है, लेकिन आखिरकार यह एक message encoding protocol है, और फिर भी मेरे server architecture को कैसे बनाना चाहिए, इस पर इसकी राय होना मुझे खटकता है
    gRPC में भी यह समस्या निश्चित रूप से है, लेकिन वह protobuf से बहुत साफ़ तौर पर अलग है, और protobuf में gRPC से जुड़ी कुछ सुविधाएँ ज़रूर हैं
    इसी उलझाव की वजह से capnp से तुलना करते समय मैं हर बार flatbuffers या protobuf की तरफ झुक जाता हूँ। खासकर इसलिए कि fb और pb implementations कहीं ज़्यादा सरल हो गए हैं, और security व maintainability के लिहाज़ से मैं simplicity को बहुत अहम मानता हूँ
    अच्छे third-party language implementations की कमी भी मुझे इस निर्णय के सही होने का सीधा संकेत लगती है। bus factor और long-term viability भी बहुत खराब हैं। simplicity हावी रहती है

    • cap'n'proto के पास जाते समय मेरी समस्या सिर्फ यह नहीं रही कि server architecture पर इसकी राय है, बल्कि C++ में यह STL के एक बहुत opinionated विकल्प KJ को भी साथ ले आता है। कुछ साल पहले जब इसे आज़माया था, तो यह मौजूदा codebase के कई हिस्सों में घुस जाता था और काम करना मुश्किल बना देता था
      Rust version भी अपना खुद का normative lifestyle मांगता है। उनमें से बहुत-सी बातें zero-copy worldview में समझ आती हैं, लेकिन फिर भी कई expressions को मुश्किल बना देती थीं और docs भी पढ़ने में कठिन थे
      इसलिए केवल इसी वजह से भी मैं आम तौर पर flatbuffers चुनता हूँ
      फिर भी उम्मीद है कि कभी cap'n'proto की सचमुच ज़रूरत और उपयोगिता वाली स्थिति आएगी, और वर्षों से इसे आज़माने के लिए fork किए गए कई hobby projects में से कम से कम एक तो पूरा करना चाहता हूँ। इसमें high-quality engineering लगी है, यह बात सही है
    • मुझे उत्सुकता है कि serialization layer RPC choice को कैसे प्रभावित करती है

  • नया तो नहीं है, लेकिन सोच रहा हूँ कि क्या नाम Star Trek Voyager को जानबूझकर दी गई tribute है, या कोई और reference है जिसे मैं नहीं जानता
    https://memory-alpha.fandom.com/wiki/Captain_Proton

    • उस reference के बारे में मैंने असल में कभी सोचा नहीं था
      Cap'n Proto नाम का मतलब मूल रूप से Capabilities and Protobufs था। यह Protocol Buffers आधारित capability-based RPC protocol था। लेकिन शुरुआती दौर में मुझे एक पूरी तरह अलग serialization format आज़माने का मन हुआ। फिर भी “Proto” protocol के अर्थ में अब भी सही था, इसलिए नाम बनाए रखा
      “cerealization protocol” वाला pun दरअसल किसी और ने मुझे बताया था, लेकिन मैंने तुरंत उसे logo में जोड़ दिया
    • इसे “cerealization protocol” के रूप में promote करते देखा था, इसलिए मैं हमेशा इसे Cap'n Crunch cereal reference समझता था
 
bbulbum 2023-07-30

लगता है यह Serialization/RPC है, शायद टाइपो है।