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