Cap'n Proto 1.0

• Pembatalan RPC dengan model opt-in diubah dari pemanggilan context.allowCancellation() menjadi anotasi allowCancellation pada schema
• Pengguna yang tidak memakai context.allowCancellation() tidak perlu melakukan perubahan saat upgrade ke 1.0, dan pembatalan tetap tidak diizinkan secara default
• 1.0 adalah rilis bergaya dukungan jangka panjang (LTS), dan ada rencana untuk melakukan backport bugfix ke branch 1.0 dalam jangka panjang
• Peningkatan performa Cap’n Proto RPC mencakup pengurangan alokasi memori pada implementasi RPC dan framework KJ I/O, penghilangan sebagian message protokol RPC, serta pengurangan syscall melalui perbaikan buffering message kecil
• KJ menggunakan kqueue() untuk menangani I/O asinkron di MacOS dan keluarga BSD, berubah dari pendekatan berbasis poll() yang sebelumnya lebih lambat
• Implementasi client dan server HTTP KJ mendukung method CONNECT
• capnp::RevocableServer ditambahkan untuk menyediakan struktur yang membantu menghindari bug use-after-free saat mengekspor objek yang wrapper-nya tidak mengontrol lifetime sebagai wrapper RPC
• Pengembangan 2.0 akan dilakukan di branch v2 yang baru, dan branch master direncanakan menjadi branch 1.0 LTS agar proyek yang sudah ada tidak terganggu oleh perubahan
• Rencana 2.0 bukan perubahan yang memutus kompatibilitas mundur pada format serialisasi atau protokol RPC, melainkan perubahan yang berfokus pada C++ API dan KJ, sehingga aplikasi yang ditulis dalam bahasa lain tidak terpengaruh
• Rencana 2.0 mencakup persyaratan compiler C++20 atau C++23, penggunaan coroutine C++20, penghentian dukungan untuk exception disabled dan mode no-RTTI, serta perubahan pada API kj::Maybe dan kj::AsyncOutputStream

[alstjr7375]

Oh.. ini akhirnya juga

[GN⁺]

Opini Hacker News

• Menyampaikan kabar yang sangat menyedihkan kepada komunitas Cap'n Proto dan Sandstorm. Ian Denhardt (zenhack di HN), kontributor inti implementasi Go, meninggal dunia secara mendadak beberapa minggu lalu. Karena selama 3 tahun terakhir banyak berkolaborasi dengannya dan menjadi teman, ini terasa sebagai kehilangan besar.
  Pada praktiknya, sebagai lead proyek, kini saya harus mengisi kekosongan besar yang ditinggalkan Ian, jadi jika Anda bisa berkontribusi pada proyek ini, bantuan sangat dibutuhkan. Jika Anda kontributor atau maintainer implementasi lain seperti C++, Rust, dan sebagainya, saya sangat ingin Anda menghubungi saya. Untuk meneruskan pekerjaan Ian, saya perlu bekerja bersama orang-orang yang sangat cerdas.
  RIP Ian, saya benar-benar belajar banyak saat bekerja bersamamu. Kontak: https://github.com/lthibault, https://matrix.to/#/#go-capnp:matrix.org, Telegram @lthibault, gmail louist87

  • Saya pernah beberapa kali mengalami orang-orang pergi secara tiba-tiba, dan itu benar-benar menghancurkan jiwa. Setiap kali hal seperti itu terjadi, saya teringat betapa rapuhnya hidup, dan betapa cepat semuanya bisa berubah.
    Saya tidak menutup mata terhadap masa depan, tetapi jadi berusaha lebih menikmati hal-hal kecil dalam hidup. Ian meninggalkan warisan luar biasa yang menyentuh banyak orang. RIP Ian
  • Saya terkejut karena belum mendengar kabar ini. Saya sangat menyukai blog Ian, sangat disayangkan
  • @zenhack tampaknya juga mengelola binding Haskell
  • Saya tidak mengenalnya secara langsung, tetapi sangat menghormati pekerjaannya pada Tempest, fork terbaru yang mencoba menghidupkan kembali Sandstorm. Terima kasih sudah memberi tahu kabar ini
  • Kabar yang benar-benar menyedihkan. Ian menginspirasi banyak orang, dan ini akan menjadi kehilangan besar bagi seluruh komunitas

• Di luar Cap'n Proto, mengejutkan bahwa hanya sedikit protokol yang memiliki promise pipelining. Contoh lain yang terlintas hanya 9p, tetapi 9p bukan protokol serbaguna
  https://capnproto.org/news/2013-12-13-promise-pipelining-cap...

  • Ini memang fitur yang keren, tetapi dibandingkan dengan cara mengelompokkan kueri secara eksplisit, sepertinya backend akan lebih sulit dioptimalkan. Misalnya, daripada beberapa panggilan RPC terpisah yang dipipeline, panggilan RPC khusus yang selesai dengan satu kueri SQL mungkin lebih baik
    Meski begitu, fitur ini rasanya layak digunakan lebih luas
  • Pipelining adalah ide yang kurang baik. Karena ia mewujudkan instance objek, implementasi yang tangguh menjadi jauh lebih sulit. Ini tidak lagi berupa panggilan stateless, melainkan struktur yang menjalankan fungsi terhadap instance objek tertentu
    Misalnya, jika klien Joe memanggil Service A lalu meneruskan hasil promise itu ke Service B, maka Service B harus melakukan panggilan jarak jauh ke Service A untuk mendapatkan hasil promise tersebut
    Pada titik ini batas keamanan langsung menjadi rumit. Model delegasinya sendiri sudah menjadi persoalan, tetapi yang lebih serius adalah hilangnya backpressure. Jika klien Joe membuat ribuan panggilan ke Service A dan meneruskan hasil yang belum diwujudkan ke Service B, Service A bisa dibanjiri seperti DDoS sehingga Service B mengalami timeout
  • Saya tidak tahu bahwa 9p memiliki promise pipelining. Lebih tepatnya, karena klien dapat memilih file descriptor, klien bisa mengirim permintaan untuk membaca file segera setelah membukanya, dan jika open gagal maka read juga gagal dengan EBADF; ini bagus
    Namun promise pipelining juga memerlukan dukungan klien. Saya penasaran apakah ada klien 9p yang, ketika pengguna menerbitkan beberapa walk, mengirim semuanya tanpa menunggu respons walk pertama
    Selain itu, 9p hanya menyediakan promise pipelining untuk file descriptor. Dengan itu saja banyak hal bisa dilakukan, tetapi jika ingin membaca semua file dalam sebuah direktori, seharusnya kita bisa menerbitkan read lalu melakukan walk berdasarkan hasil read tersebut; tampaknya 9p tidak mendukung ini. Di library protokol remote system call saya, rsyscall, hal ini benar-benar didukung
  • Leluhur spiritual Cap'n Proto mencakup CapTP/VatTP, alias Pluribus, yang dikembangkan bersama bahasa E milik Mark Miller. Sebagai permainan nama, ada juga perangkat bernama “unum”. Untuk silsilah yang lebih dalam, lihat disertasinya; di sana juga dibahas promise pipelining dari Barbara Liskov dan ide-ide terkait dari Argus, ekstensi CLU
    Seingat saya, Mark Miller kemudian juga menulis proposal promise untuk JavaScript. Namun ekstensi RPC-nya tidak terwujud, dan sebagai gantinya kita mendapatkan async/await, yang tampaknya kurang cocok dengan pipelining
    Spritely Goblins dan OCapN, upaya yang lebih baru untuk membangun sistem kapabilitas terdistribusi ala E, juga mengejar pipelining, jadi jika Anda berada di cap-talk, kemungkinan Anda bisa mendengar beberapa protokol serupa lagi meskipun kasus penggunaan nyatanya sedikit
    Namun meski ini fitur yang keren, promise pipelining tampaknya mengharuskan kita memprogram dengan promise eksplisit sungguhan, dan sudah diketahui betapa rumitnya itu bisa menjadi
    Di sisi lain, yaitu event loop dan “active object” dengan eksekusi konkuren kooperatif, ada ide menarik dan kurang dikenal dari DCOM/COM+, yaitu causality IDs. Ini adalah sarana untuk mengendalikan reentrancy; lihat dokumentasi Microsoft tentang CoGetCurrentLogicalThreadId dan pembahasan CALLTYPE_TOPLEVEL_CALLPENDING di Effective COM. Belakangan, tampaknya mereka sempat mencoba menjualnya sebagai fitur baru di ASTA Win8/UWP
    [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...
  • Saya tidak tahu persis bagaimana promise pipelining di Cap'n Proto bekerja, tetapi saya khawatir pada kasus ketika ingin membaca direktori lalu melakukan stat pada semua entri di dalamnya, atau ketika ingin meneruskan hanya salah satu dari dua nilai respons ke panggilan berikutnya
    Yang terakhir rasanya mungkin bisa dilakukan dengan suatu cara, tetapi yang pertama bergantung pada jumlah nilai dalam daftar hasil, dan sebagainya

• Selamat atas rilisnya. Setelah 10 tahun, pasti rasanya sangat menggembirakan. Saya penasaran apakah ke depannya akan ada lebih banyak pekerjaan pada implementasi bahasa lain
  Saya sangat menyukai ide formatnya, tetapi bahasa utama dalam stack kami belum didukung sampai tingkat yang membuat kami ingin memakainya di produk

  • Bagian ini memang kelemahan terbesar Cap'n Proto. Satu-satunya yang benar-benar saya kelola adalah implementasi C++, sedangkan implementasi lain datang dari berbagai kontributor, sehingga tingkat kelengkapan dan kualitasnya beragam
    Sayangnya sulit bagi saya untuk menjanjikan hal baru di sini. Pekerjaan pada Cap'n Proto digerakkan oleh kebutuhan proyek utama saya, runtime Cloudflare Workers, dan itu terutama C++. Ia juga berinteraksi dengan layanan Go dan Rust, dan implementasi terkait tampaknya menjalankan perannya di sana
    Dengan kata lain, Cap'n Proto adalah proyek open source dan saya berharap berguna bagi orang-orang, tetapi ini bukan produk yang ingin saya jual, jadi saya tidak secara khusus berfokus membuat semua orang mengadopsinya. Seperti biasa, kontribusi sangat diterima
    Satu skenario yang bisa membawa perubahan besar adalah jika Cloudflare memutuskan menjadikan Cap'n Proto sebagai fitur publik di platform Workers. Itu akan menciptakan kebutuhan langsung untuk benar-benar memolesnya di banyak bahasa. Kadang hal ini dibahas, tetapi saat ini belum ada rencana
  • Ada orang-orang yang mencoba menulis langsung lapisan RPC, bukan wrapper yang membungkus implementasi C++, tetapi kode yang harus ditulis ulang sangat banyak dibandingkan manfaat langsungnya
    Kalau ingin mencoba, silakan saja. Kemungkinan orang-orang akan cukup kooperatif. Namun perlu diketahui bahwa pekerjaannya memang sangat banyak

• Sebagai latar belakang tambahan, Kenton menjalankan sistem proto internal Google selama bertahun-tahun, lalu setelah keluar membuat versi open source miliknya sendiri

  • Kemungkinan dialah orang yang merilis protobuf sebagai open source

• Jika ada karyawan Cloudflare yang terlibat dalam pemilihan Cap'n Proto dibanding alternatif lain seperti protobuf, saya penasaran pertimbangannya apa. Saya ingin tahu apakah alasannya juga penting bagi saya, atau apakah itu hal yang tidak perlu dipikirkan kecuali berurusan dengan skala yang sangat besar

  • Ada artikel blog yang membahas penggunaan Cap'n Proto oleh Cloudflare pada 2014, tiga tahun sebelum saya bergabung: https://blog.cloudflare.com/introducing-lua-capnproto-better...
    Hingga kini, pipeline data Cloudflare—yakni sistem yang membuat log dan analitik di edge—sebagian besar masih berbasis serialisasi Cap'n Proto. Saya pribadi tidak banyak terlibat dalam proyek itu
    Untuk Cloudflare Workers, karena saya yang memulai proyeknya, saya memakai milik saya sendiri. Mungkin itu bukan penjelasan yang Anda cari
    Meski begitu, menurut saya protokol RPC Cap'n Proto jauh lebih ekspresif daripada alternatifnya, sehingga sangat membantu dalam implementasi sandboxing Workers Runtime dan fitur sistem terdistribusi seperti Durable Objects. https://blog.cloudflare.com/introducing-workers-durable-obje...
  • Saya tidak bekerja di Cloudflare, tetapi mengikuti pekerjaan mereka dan kadang menangani proyek yang sensitif terhadap performa. Dugaan saya, Cap'n Proto, flatbuffers, SBE, dan sejenisnya dilihat sebagai kategori yang berbeda dari format data lain seperti Avro atau protobuf
    Jika memilih data yang bentuknya lebih dekat ke record, bukan berorientasi kolom seperti Parquet, dan menginginkan format dengan waktu parsing awal yang praktis nol, pilihannya menjadi cukup sedikit. Jika nilai field diubah saat membaca, marshalling masih bisa terjadi
    https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... membahas trade-off ini
    Cap'n Proto awalnya dibuat untuk https://sandstorm.io/, dan pekerjaan yang kemungkinan dilakukan Kenton setelah direkrut Cloudflare pada akhirnya mengarah ke Cloudflare Workers
    Pertimbangan lain: https://github.com/google/flatbuffers/issues/2#issuecomment-...
  • Merangkum situasi sekitar sedikit lebih dari setahun setelah saya bergabung, Cloudflare sedang membangun cara untuk mengirim log dari edge ke titik pusat guna menyediakan analitik pelanggan dan log bagi pelanggan enterprise
    Albert Strasheim, engineer inti yang membangun keseluruhan sistem itu, melakukan benchmark terhadap opsi serialisasi yang kuat, dan sejauh yang saya pahami hasilnya menunjukkan Cap'n Proto cukup jauh lebih cepat daripada protobuf
    Ada implementasi C++ yang bagus, dan bisa digunakan di nginx. Seingat saya ada sedikit Lua yang juga terlibat. Implementasi Go yang dipakai di sisi konsumsi memiliki beberapa bagian kasar, tetapi bagian inti yang dibutuhkan bisa diperbaiki oleh orang-orang
    Cloudflare selalu sangat mementingkan efisiensi biaya mesin, jadi dengan mempertimbangkan kebutuhan performa saat itu, pilihan tersebut terasa wajar. Selama saya berada di tim data, Cap'n Proto cukup mudah dikerjakan, dan cara berbagi definisi proto dari repositori skema pusat juga berjalan baik
  • Karena lead developer Cloudflare Workers adalah pencipta Cap'n Proto, kemungkinan pilihan itu menjadi mudah

• Saya antusias melihat Cap'n Proto ikut serta dalam pekerjaan standardisasi OCapN. Saya penasaran apakah ini akan menjadi bagian dari pekerjaan Cap'n Proto 2.0
  https://github.com/ocapn/ocapn

  • Sayangnya, Ian “zenhack” Denhardt, yang memimpin keterlibatan itu, baru-baru ini meninggal dunia secara mendadak
    Saya menyukai OCapN, tetapi dengan banyaknya pekerjaan yang sedang saya tangani sekarang, saya tidak tahu berapa banyak waktu yang bisa saya curahkan secara pribadi. Saya berharap bisa menyampaikan kabar yang lebih baik, tetapi ini adalah kehilangan tragis bagi kita semua

• Saya belum pernah memakai Cap'n Proto, tetapi saya berterima kasih atas jawaban FAQ kentonv yang sangat informatif [1], yang menjelaskan mengapa field wajib menjadi masalah dalam protokol
  Saya sering menautkannya setiap kali orang bertanya mengapa protobuf 3 tidak memiliki field required
  [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...

  • Ini benar-benar sudut pandang yang berharga. Dulu saya juga sulit memahaminya. Intinya adalah memahami protobuf dan Cap'n Proto bukan sebagai struktur data in-memory yang merepresentasikan dunia seperti dilihat satu proses dengan satu versi, melainkan sebagai format serialisasi yang harus bekerja melintasi batas API dengan versi skema yang berbeda serta kompatibilitas mundur dan maju
    Jadi mantra yang sering diulang, “buat state ilegal tidak mungkin direpresentasikan”, tidak berlaku di sini
  • Typical menyediakan field asimetris untuk membantu evolusi tipe:
    https://github.com/stepchowfun/typical#asymmetric-fields-can...
    Agar bisa menambahkan dan menghapus field wajib dengan aman, Typical menyediakan asymmetric, yakni keadaan perantara antara field opsional dan field wajib. Field asymmetric dalam sebuah struct dianggap wajib bagi penulis, dan opsional bagi pembaca. Berbeda dengan field opsional, field asymmetric dapat dipromosikan dengan aman menjadi wajib, atau dikembalikan sebaliknya
  • Jika logika ini diperluas, rasanya bisa juga sampai pada kesimpulan untuk menghapus hampir semua static type. Jujur saja, itu tidak sepenuhnya salah, dan itulah alasan Alan Kay mendefinisikan object-oriented dengan dynamic type dan late binding. Namun kita justru bergerak ke arah sebaliknya sambil terus mempelajari ulang pelajaran yang sama
  • FAQ [1] mengatakan, “jawaban yang benar adalah aplikasi melakukan validasi di kode tingkat aplikasi sesuai kebutuhan”
    Daripada bergantung pada kode aplikasi, saya berharap ada parameter untuk menyalakan dan mematikan validasi pesan wajib. Di dalam aplikasi atau message bus bisa dimatikan, tetapi secara umum jika menyala itu sangat membantu developer
    [1] https://capnproto.org/faq.html#how-do-i-make-a-field-require...
  • Ada satu jebakan lagi dalam konteks yang sama. Masalahnya adalah hal-hal yang tidak diperlukan ikut dideserialisasi, seperti yang diterima dari client yang dihasilkan
    Hal yang sangat saya sukai dari interface di Go adalah saya bisa mengetikkan secara remote hanya bagian yang saya gunakan dan melewati sisanya. Layanan yang gagal karena perubahan kontrak yang bahkan tidak dipakainya itu tidak menyenangkan, dan sulit ditemukan

• Ini pencapaian yang hebat. Kalau boleh jujur, saya tidak akan merekomendasikan Cap'n Proto. API C++-nya sangat canggung
  Manfaat zero-copy parsing juga lebih kecil dari yang diharapkan. Karena usability-nya canggung, kemungkinan kecil Anda ingin terus menyimpan data dalam struktur data Cap'n Proto, dan 99% akhirnya akan menyalinnya ke struktur data sendiri
  Dunia pada umumnya sudah menetap pada Protobuf untuk implementasi biner semacam ini, sehingga gesekan dengan sistem lain juga lebih besar
  Saya hanya pernah memakainya untuk serialisasi. Sisi RPC mungkin bisa lebih menarik
  Saya benar-benar berharap Thrift yang berhasil, bukan Protobuf/gRPC. Desainnya jauh lebih bagus dan fleksibel daripada apa pun yang pernah saya lihat sebelum maupun sesudahnya. Sepertinya ia menghilang terutama karena dokumentasinya buruk, dan mungkin juga karena tidak ada nama besar di belakangnya

  • Saya setuju bahwa API yang diperlukan untuk zero-copy menjadi agak canggung, terutama di sisi penulisan. Di sisi pembacaan tidak terlalu berbeda. Di sisi lain, zero-copy hanya benar-benar seperti perubahan paradigma dalam skenario tertentu, seperti saat digunakan bersama mmap(); dalam komunikasi jaringan, tidak banyak berubah kecuali memakai teknik kuat seperti RDMA
    Untuk use case ketika zero-copy tidak terlalu penting, saya selalu ingin menambahkan API alternatif opsional ke Cap'n Proto yang memakai “struct C biasa” atau bentuk yang mendekatinya, dan menyediakan serialisasi dengan satu kali copy seperti protobuf, tetapi belum sempat melakukannya
    Namun secara pribadi, saya jauh lebih tertarik pada protokol RPC daripada serialisasi. Saya pikir protokol RPC adalah perubahan paradigma nyata untuk hampir semua use case yang tidak trivial
  • Sepertinya yang Anda maksud bukan protobuf, melainkan flatbuffers. Itu praktis sudah menjadi standar, dan beberapa tempat lain memakai SBE
    Bagaimanapun, masalah utama serialisasi biner adalah manajemen versi skema dan pesan, serta delta encoding. Jika keduanya diabaikan, serialisasi biner datar itu sepele
    Tidak ada library yang menyediakan solusi yang menangani kedua hal di atas dengan baik
  • Jika tidak membutuhkan skema, menurut saya MessagePack cukup bagus. Namun serialisasi JSON di V8 luar biasa cepat sehingga MessagePack pun sulit mengalahkannya; di bahasa lain sering kali lebih cepat, dan memang mengurangi jumlah byte
  • fbthrift masih hidup dengan baik

• Saya selalu menyukai ide capnp, tetapi pada akhirnya yang mengganggu adalah fakta bahwa, sebagai protokol encoding pesan, ia juga punya opini sampai ke bagaimana saya harus merancang arsitektur server saya
  gRPC jelas juga punya masalah seperti ini, tetapi ia terpisah sangat jelas dari protobuf, meskipun protobuf memang punya fitur terkait gRPC
  Karena keterkaitan seperti ini, setiap kali membandingkannya dengan capnp saya jadi cenderung memilih flatbuffers atau protobuf. Terutama karena implementasi fb dan pb jauh lebih sederhana, dan saya sangat menghargai kesederhanaan dari sisi keamanan dan pemeliharaan
  Kurangnya implementasi bahasa pihak ketiga yang bagus juga saya anggap sebagai sinyal langsung bahwa penilaian ini masuk akal. Bus factor dan kelangsungan hidup jangka panjangnya juga sangat buruk. Kesederhanaanlah yang menang

  • Masalah yang saya alami setiap kali mendekati cap'n'proto bukan hanya ia punya opini tentang arsitektur server, tetapi di C++ ia juga membawa KJ, alternatif STL yang sangat opinionated. Saat saya mencobanya beberapa tahun lalu, ia menjangkau banyak bagian di codebase yang sudah ada sehingga sulit dikerjakan
    Versi Rust-nya juga menuntut gaya hidup normatifnya sendiri. Banyak di antaranya masuk akal dalam worldview zero-copy, tetapi tetap saja membuat berbagai bentuk ekspresi menjadi sulit dan dokumentasinya juga sulit dibaca
    Jadi, karena alasan ini saja biasanya saya memilih flatbuffers
    Meski begitu, saya berharap suatu hari akan ada situasi ketika cap'n'proto diperlukan dan berguna, dan saya ingin menyelesaikan setidaknya salah satu dari beberapa proyek hobi yang sudah saya fork selama bertahun-tahun untuk mencobanya. Memang benar ada engineering berkualitas tinggi di dalamnya
  • Saya penasaran bagaimana lapisan serialisasi memengaruhi pilihan RPC

• Ini bukan hal baru, tetapi saya penasaran apakah namanya memang penghormatan yang disengaja untuk Star Trek Voyager, atau ada referensi lain yang tidak saya ketahui
  https://memory-alpha.fandom.com/wiki/Captain_Proton

  • Referensi itu sebenarnya tidak pernah saya pikirkan
    Nama Cap'n Proto awalnya berarti Capabilities and Protobufs. Itu adalah protokol RPC berbasis kapabilitas yang didasarkan pada Protocol Buffers. Namun sejak awal saya jadi ingin mencoba format serialisasi yang sepenuhnya berbeda. Meski begitu, “Proto” tetap cocok karena berarti protokol, jadi nama itu dipertahankan
    Permainan kata “cerealization protocol” sebenarnya diberitahukan oleh orang lain kepada saya, tetapi saya langsung menambahkannya ke logo
  • Karena mereka mempromosikannya sebagai “cerealization protocol”, saya selalu mengira itu referensi ke sereal Cap'n Crunch

[bbulbum]

Sepertinya itu maksudnya Serialization/RPC, jadi mungkin ada typo.