Hi Jiaming, Thanks for pushing CppClient forward and sharing the status. A year of work with a functional readClient is great progress; keeping writerClient in development makes sense given JavaClient’s pace. I fully support merging a basic, end‑to‑end write‑read path as the first milestone. Feature parity with JavaClient can follow—let’s get something usable into the repo and iterate. I’m willing to start using and testing CppClient right after the first milestone is reached to help polish behavior, file issues, and contribute PRs.
Thanks, Ethan Feng Mridul Muralidharan <[email protected]> 于2025年11月2日周日 06:49写道： > > Hi, > > Having a version which supports end to end functionality - even if just a > subset of features - will be invaluable. > > In our docs, we can simply “tag” whether a particular feature/config is > supported or not. > > In time, we will bridge the gap and ensure parity - but it is not practical > to assume CppClient will be able to do all that scala client does > immediately :) > > Getting it into the hands of users and allowing third party integrations > might also give us valuable feedback in terms of what to prioritize as well > . > > Thanks for driving the effort - we are planning to leverage CppClient with > native execution, and so waiting for the first version with e2e support :) > > Regards, > Mridul > > > > On Sat, Nov 1, 2025 at 9:10 AM rexxiong <[email protected]> wrote: > > > Hi Jiaming, > > > > Thanks for sharing your thoughts! > > > > I agree that the first milestone for CppClient should be to implement a > > working write-read procedure and make it usable ASAP. However, I also > > believe it’s important for us to have some planning and tracking mechanisms > > for the CppClient’s feature development. For example, it would help if we > > could clearly outline CppClient’s capabilities for each major version, as > > well as what features are not yet aligned with JavaClient. > > > > I recommend we start using Jira to track all pending tickets for CppClient, > > and adjust our roadmap as needed based on progress and priorities. > > Additionally, it will be helpful to summarize CppClient’s feature status > > and progress in the release notes of each version, so users and > > contributors have a clear understanding of what's available and what's > > still in development. > > > > Let me know what you think or if you have any other ideas! > > > > Thanks, > > Jiashu Xiong > > > > Nicholas Jiang <[email protected]> 于2025年10月30日周四 20:58写道： > > > > > Hi Jiaming, > > > > > > Thanks for driving the discussion about the aligment between CppClient > > and > > > JaveClient. IMO, It is hard to define a mechanism to guarantee the > > aligment > > > at present. If it's difficult to guarantee alignment, then it's necessary > > > to ensure that CppClient is aligned with a certain version. Otherwise, > > the > > > features of CppClient are uncertain for release version. BTW, could you > > > provide the supported features of current CppClient? > > > > > > Regards, > > > Nicholas Jiang > > > > > > On 2025/10/30 07:52:02 Jiaming Xie wrote: > > > > Hi Celeborn Community, > > > > > > > > I've been working on CppClient's code for about a year. Currently the > > > > readClient's code is functional, and the writerClient's code is under > > > > development. > > > > > > > > But as the JavaClient has plenty of features, it is hard to implement > > > > all of them at the same time. Besides, when I am working on the > > > > CppClient's code, the JavaClient has been iterating as well, and the > > > > CppClient might lack some additional features in JavaClient. > > > > > > > > Personally, I think for CppClient the first milestone is to finish a > > > > complete write-read procedure and make it a usable feature. So I > > > > choose to implement only the basic ones to make sure we could achieve > > > > the complete write-read milestone ASAP. But when I want to merge the > > > > code, I find that the cpp code to be merged is not strictly identical > > > > to JavaClient, and I am not sure if it is ok to simply mark the lacked > > > > features as TODOs and continue to merge the cpp code though it might > > > > lack some features compared with Java end. > > > > > > > > Besides, currently there is no mechanism to guarantee that the > > > > JavaClient's feature development would soon iterate on CppClient as > > > > well. Maybe we should add some kind of tag to at least mark what > > > > features the CppClient lacks. > > > > > > > > Any suggestions and thoughts are welcome. > > > > > > > > Yours, > > > > Jiaming Xie > > > > > > > > >
