For the first milestone, there is no difference between different front end. The idk parse is already finished. All other work should be unrelated to frontend anyone.
For zero-copy, it's just to avoid buffer copy instead of flatbuffer style support. We still need parse object. On Tue, Mar 24, 2026 at 10:00 PM viking deng <[email protected]> wrote: > Hi Chaokun, > > I’m preparing my application for the Apache Fory GSoC 2026 project on C++ > & Rust gRPC Integration, and I wanted to briefly introduce myself and share > some of the preparation I’ve done so far. > > I’m currently a Master’s student at Beihang University, majoring in > Computer Science. I previously interned at Shopee and ByteDance, where I > worked on backend development and infrastructure related to large-scale > systems. My main interests are in systems, serialization, compiler/code > generation, and cross-language infrastructure. I’m also very interested in > open-source collaboration, which is one of the main reasons I’m excited > about contributing to Apache Fory. > > Over the past few days, I did a deeper local bring-up of the compiler and > the current C++ / Rust paths. Based on that exploration, my current > understanding is that: > > - service IR and parsing are already in place > - the compiler CLI already exposes the gRPC-related path > - the main remaining work is around C++ / Rust service generation, > transport bindings, codec integration, interoperability tests, examples, > and CI > > While going through this path, I found and fixed a small issue in the > compiler service example, and my PR has been merged: > > https://github.com/apache/fory/pull/3505 > > I kept this contribution intentionally small and focused, so that it > improves the current compiler/service workflow without overlapping with the > main gRPC backend implementation. > > I’m currently organizing my proposal around the following parts: > > - C++ and Rust service generation > - Fory-based request/response codec integration > - zero-copy inbound fast path with safe fallback > - interoperability tests, runnable examples, and CI coverage > > If you have time, I would really appreciate your feedback on two points: > > 1. For the first milestone, would you prefer an FDL-first > implementation and then proto/FBS parity later, or should all frontends be > exercised from the beginning? > 2. For “zero-copy support”, is the intended target specifically to > avoid an extra transport-buffer-to-decode-input copy when borrowing is > safe? > > I’m polishing my full proposal now, and I’d be very glad to share a short > design note as well if that would be helpful. > > Best regards, > Weijian Deng >
