1. The byte-for-byte assertion is not the target of this project. This project focuses on grpc integration, not the serialization. 2. The GRPC integration is not coupled with fory mode, all xlang mode should be supported. It's totally orthogonal
On Wed, Mar 18, 2026 at 9:17 PM Dimitris Kall <[email protected]> wrote: > > Hi Chaokun, > > Thank you for the clarification, both points are clear. > > Regarding the Marshaller, I wanted to confirm my understanding of the > constraint that no new dependency can be introduced to the Fory serialization > library. The generated *Grpc.java will be fully self-contained, with the > Marshaller implemented entirely as generated code. For the Java Python > integration, I restructured the proposal to place the bidirectional > cross-language workflow at the center of the deliverable, instead of treating > Java and Python as separate phases. The integration tests (Java server > to/from Python client and Python server to/from Java client), along with a > shared CI pipeline, are now positioned as the primary validation of the > project. > > I have two questions where I would really appreciate your guidance before > finalizing: > > The proposal uses semantic equality (field-by-field comparison) rather than > byte-for-byte assertions in integration tests, since raw bytes may not be > stable across languages when registration metadata differs. Do you consider > semantic equality sufficient for primary assertions, or should byte-level > stability be expected and tested in the initial unary case? > For the Fory instance configuration in the generated createFory() factory, is > there a preferred combination of modes (e.g., xlang mode, reference tracking, > compatible mode) that the gRPC integration should target? Or should the > factory expose these options and leave defaults to the caller? > > I have attached the revised proposal as a PDF. I would be very grateful for > any feedback before the submission deadline, particularly on whether the > proposed design and implementation for Java (#3272) and Python (#3273) gRPC > code generation aligns with your expectations. > > Thank you again for your time and consideration. > > Best regards, > Dimitris Kalligaridis > > On Tue, Mar 17, 2026 at 4:47 AM Shawn Yang <[email protected]> wrote: >> >> Hi Dimitris, >> >> Thank you for your interest in the project and for reading through the >> related issues and docs. >> >> For GSoC, a pure Java project would not be acceptable. The project is >> expected to include both Java and Python aspects, with clear >> integration between them. >> >> Regarding whether the generated *Grpc.java should handle Marshaller >> instantiation entirely in generated code or rely on a small runtime >> helper class, that is a design choice and should be discussed and >> justified in your proposal. >> >> Best, >> Shawn Yang >> >> On Tue, Mar 17, 2026 at 1:38 AM Dimitris Kall >> <[email protected]> wrote: >> > >> > Hi Chaokun, >> > >> > I am Dimitris, a senior IT student at The American College of Greece. I >> > interned at Amazon last summer where I worked in Java and Go on backend >> > microservices at production scale, and I have been writing Python for >> > about 5 years now across personal-projects, research, and production >> > contexts. I am very interested in the Java and Python gRPC integration >> > project for GSoC 2026. >> > >> > I have read issues #3272 and #3273, the compiler guide and the >> > grpc-service-design doc. The part I want to make sure I understand >> > correctly before drafting a proposal is the Fory Marshaller for Java gRPC, >> > is the expectation that the generated *Grpc.java handles Marshaller >> > instantiation entirely through generated code, or will there be a small >> > runtime helper class that the generated code depends on? I want to scope >> > the Java deliverable accurately in my proposal. >> > >> > I am looking forward to hearing from you. Thank you for your time and >> > consideration. >> > >> > Best regards, >> > Dimitris >> > GitHub | LinkedIn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
