Hi Celeborn Community,
Thanks for your thoughts, really provide great insights. According to the
discussions above, I think there are following actions to be carried out:
1. In order to provide an end-to-end workable CppClient ASAP, the CppClient's
code could be merged even if it does not have all functionalities
of JavaClient.
2. In order to keep track of the lacking functionalities, a tracking
jira should be
added. I've create an empty jira in [1], and will add the missing
feature jiras
to it.
3. In order to keep new JavaClient features trackable for CppClient in
the future,
we should add some kind of mechanism. My thought is that the PR template
should be modified to add a new question, something like "Does
this PR involve
client code and should be supported in Cpp Code?" And when the answer is
Yes, the MR should be labelled as "cpp-to-align", and we should
add a new sub
jira under the tracking jira in action#2. The procedure should be
easily supported
by some kind of bot.
I am not sure if action#3 is proper enough, and any thoughts or
opinions would be
greatly appreciated.
Thanks,
Jiaming Xie
[1] https://issues.apache.org/jira/browse/CELEBORN-2199
Ethan Feng <[email protected]> 于2025年11月3日周一 15:42写道：
>
> 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
> > > > >
> > > >
> > >
