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 > > > > > >
