Thanks William for the suggestion! This is really good feedback and I
totally agree with that!

Documentation will be part of the project lists :)

- *User guide / configuration documentation*: Document all the features
supported by Helix and update the configurations / examples.

On Thu, Jun 20, 2024 at 2:46 PM William Morgan <[email protected]>
wrote:

> If a large rewrite for 2.0 were to occur, I would ask that the
> documentation for Helix be included as a deliverable. The current
> documentation around how the system works, what configuration items mean,
> and how to utilize core pieces of the system (Tasks, spectators, etc.) with
> solid examples for most common usecases would greatly help current users of
> the product.
>
> As someone who uses Helix heavily, all the listed features sound amazing.
> I actually built a rudimentary version of the gRPC gateway for helix for my
> company for the exact reason stated.
>
> Thanks,
>
> Will
>
> > On Jun 20, 2024, at 5:13 PM, Junkai Xue <[email protected]> wrote:
> >
> > Hi All,
> >
> > Apache Helix has been stable for a long time, but there are several areas
> > where we can make significant improvements. I am proposing a new
> generation
> > of Apache Helix with the following major goals:
> >
> > 1. Multi-language support
> > 2. Simpler API and user experience
> > 3. Improved data model, communication protocol, and system performance
> > 4. More pluggabilities
> >
> > To achieve these goals, I have outlined the following projects:
> >
> > - *Multi-language support*: Develop a gateway service that accepts
> general
> > state transition calls through gRPC.
> >
> > - *API simplification*: Minimize both client and Admin APIs to streamline
> > the process.
> >
> > - *Simplified data model and communication protocol*: Instead of
> defining a
> > fine-grained state model, provide users with the final state and allow
> the
> > application to progressively update its own partition states. This will
> > minimize round trips between the Helix controller and participants and
> > reduce traffic to the storage (Zookeeper).
> >
> > - *Components "micro-servicing"*: Abstract some components to offer the
> > capability to plug user own logic. For example, choose move one partition
> > at a time as movement strategy instead of using per partition N -> N + 1
> by
> > default.
> >
> > Please let us know your suggestions or concerns. Thank you for your
> > attention and continuously support!
> >
> > Best,
> >
> > Junkai
>


-- 
Junkai Xue

Reply via email to