You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by yukon <yu...@apache.org> on 2021/10/01 01:37:06 UTC
Re: [DISCUSS] RIP-25 Ease of Use Improvements on RocketMQ Client API
Great catch, we will draft a new version of client APIs in few days~
On Wed, Sep 29, 2021 at 4:19 PM dongeforever <do...@apache.org>
wrote:
> The idea is OK.
> And the same time, it is better to show more details. Maybe drafting the
> new API interface is a good way to dive deep.
>
> caigy <cs...@163.com> 于2021年9月28日周二 下午5:40写道：
>
> > RIP-25 Ease of Use Improvements on RocketMQ Client API
> >
> >
> > * Current Status: Draft
> > * Authors: caigy https://github.com/caigy
> > * Shepherds: duhengforever duhengforever@apache.org
> > * Mailing List discussion: dev@rocketmq.apache.org
> > * Pull Request: #PR_NUMBER
> > * Released: <released_version>
> >
> >
> > Background & Motivation
> > ________________________________
> >
> > What do we need to do
> > * will we add a new module? No.
> > * will we add new APIs? Yes.
> > * will we add new feature? No.
> >
> >
> > Why should we do that
> > * Are there any problems of our current project?
> > Currently, RocketMQ's client API is a bit complex, and there exists
> > some unreasonable encapsulation. For example:
> > ** There are 20 methods for sending messages in DefaultProducer, with
> > lack of encapsulation, which increases complexity in usage.
> > ** DefaultMQPushConsumer provides 10 constructors，which may make user
> > difficult to choose one.
> > ** Class Message provides constructors with and without arguments,
> and
> > also provides getters/setters to operate fields of it, which lacks good
> > separation of required and non-required arguments.
> > API is important media for users to interact with RocketMQ, and it is
> > worth investing effort in optimizing its design.
> >
> > * What can we benefit proposed changes?
> > Provide clear and easier-to-understand API of RocketMQ, make it
> easier
> > to use, especially for beginners.
> >
> >
> >
> > Goals
> > ________________________________
> >
> > * What problem is this proposal designed to solve?
> > Optimize RocketMQ client APIs, including Producer, Consumer and
> > Message, remove unnecessary APIs, and provide better encapsulation.
> Current
> > unreasonable APIs will be marked deprecated and will be removed in the
> > future. After this optimization, the APIs should keep as stable as
> possible.
> >
> > * To what degree should we solve the problem?
> > We wish developers can use RocketMQ more easily with new APIs.
> >
> >
> > Non-Goals
> > ________________________________
> >
> > * What problem is this proposal NOT designed to solve?
> > This proposal will NOT change feature and performance.
> >
> > * Are there any limits of this proposal?
> > Nothing specific.
> >
> >
> >
> > Changes
> > ________________________________
> >
> > * Architecture
> > No architecture changes in this proposal.
> >
> > * Interface Design/Change
> > ** Method signature changes. Yes.
> > For example:
> > *** Add generic to support data type of message body in Message.
> > *** Support chain-call instantiation of Producer, Consumer,
> > Message, eg：Message<String>.builder().topic("msg topic").body("msg
> > body").build();
> > *** Producer provides unified and stable send() API, which is like
> > write() method of UNIX file I/O.
> > *** Add asynchronous message consumption API based on
> > CompletableFuture in Consumer.
> > *** etc...
> >
> > ** Method behavior changes. No. CLI command changes. No.
> > ** Log format or content changes. No.
> >
> > * Compatibility, Deprecation, and Migration Plan
> > ** Are backward and forward compatibility taken into consideration?
> > Optimized APIs should NOT affect compatibility, some APIs would be
> > marked deprecated. New features will use optimized APIs, encouraging
> users
> > not to use deprecated APIs.
> >
> > ** Are there deprecated APIs?
> > Yes. Some unreasonable APIs will be deprecated in this RIP.
> >
> > ** How do we do migration?
> > Unreasonable APIs are marked deprecated in this proposal, and will
> > be removed in the future.
> >
> > * Implementation Outline
> > We will implement the proposed changes by 1 phase.
> > Phase 1
> > 1. Collect pain points in using RocketMQ client APIs and redesign
> > them.
> > 2. Optimize those APIs.
> > 3. Mark previous APIs deprecated.
> >
> >
>
Re: [DISCUSS] RIP-25 Ease of Use Improvements on RocketMQ Client API
Posted by Zhanhui Li <li...@apache.org>.
Agree, exiting API set require substantial improvement, to further refine
RocketMQ model.
On Fri, Oct 1, 2021 at 9:37 AM yukon <yu...@apache.org> wrote:
> Great catch, we will draft a new version of client APIs in few days~
>
> On Wed, Sep 29, 2021 at 4:19 PM dongeforever <do...@apache.org>
> wrote:
>
> > The idea is OK.
> > And the same time, it is better to show more details. Maybe drafting the
> > new API interface is a good way to dive deep.
> >
> > caigy <cs...@163.com> 于2021年9月28日周二 下午5:40写道：
> >
> > > RIP-25 Ease of Use Improvements on RocketMQ Client API
> > >
> > >
> > > * Current Status: Draft
> > > * Authors: caigy https://github.com/caigy
> > > * Shepherds: duhengforever duhengforever@apache.org
> > > * Mailing List discussion: dev@rocketmq.apache.org
> > > * Pull Request: #PR_NUMBER
> > > * Released: <released_version>
> > >
> > >
> > > Background & Motivation
> > > ________________________________
> > >
> > > What do we need to do
> > > * will we add a new module? No.
> > > * will we add new APIs? Yes.
> > > * will we add new feature? No.
> > >
> > >
> > > Why should we do that
> > > * Are there any problems of our current project?
> > > Currently, RocketMQ's client API is a bit complex, and there exists
> > > some unreasonable encapsulation. For example:
> > > ** There are 20 methods for sending messages in DefaultProducer,
> with
> > > lack of encapsulation, which increases complexity in usage.
> > > ** DefaultMQPushConsumer provides 10 constructors，which may make
> user
> > > difficult to choose one.
> > > ** Class Message provides constructors with and without arguments,
> > and
> > > also provides getters/setters to operate fields of it, which lacks
> good
> > > separation of required and non-required arguments.
> > > API is important media for users to interact with RocketMQ, and it
> is
> > > worth investing effort in optimizing its design.
> > >
> > > * What can we benefit proposed changes?
> > > Provide clear and easier-to-understand API of RocketMQ, make it
> > easier
> > > to use, especially for beginners.
> > >
> > >
> > >
> > > Goals
> > > ________________________________
> > >
> > > * What problem is this proposal designed to solve?
> > > Optimize RocketMQ client APIs, including Producer, Consumer and
> > > Message, remove unnecessary APIs, and provide better encapsulation.
> > Current
> > > unreasonable APIs will be marked deprecated and will be removed in the
> > > future. After this optimization, the APIs should keep as stable as
> > possible.
> > >
> > > * To what degree should we solve the problem?
> > > We wish developers can use RocketMQ more easily with new APIs.
> > >
> > >
> > > Non-Goals
> > > ________________________________
> > >
> > > * What problem is this proposal NOT designed to solve?
> > > This proposal will NOT change feature and performance.
> > >
> > > * Are there any limits of this proposal?
> > > Nothing specific.
> > >
> > >
> > >
> > > Changes
> > > ________________________________
> > >
> > > * Architecture
> > > No architecture changes in this proposal.
> > >
> > > * Interface Design/Change
> > > ** Method signature changes. Yes.
> > > For example:
> > > *** Add generic to support data type of message body in Message.
> > > *** Support chain-call instantiation of Producer, Consumer,
> > > Message, eg：Message<String>.builder().topic("msg topic").body("msg
> > > body").build();
> > > *** Producer provides unified and stable send() API, which is
> like
> > > write() method of UNIX file I/O.
> > > *** Add asynchronous message consumption API based on
> > > CompletableFuture in Consumer.
> > > *** etc...
> > >
> > > ** Method behavior changes. No. CLI command changes. No.
> > > ** Log format or content changes. No.
> > >
> > > * Compatibility, Deprecation, and Migration Plan
> > > ** Are backward and forward compatibility taken into consideration?
> > > Optimized APIs should NOT affect compatibility, some APIs would
> be
> > > marked deprecated. New features will use optimized APIs, encouraging
> > users
> > > not to use deprecated APIs.
> > >
> > > ** Are there deprecated APIs?
> > > Yes. Some unreasonable APIs will be deprecated in this RIP.
> > >
> > > ** How do we do migration?
> > > Unreasonable APIs are marked deprecated in this proposal, and
> will
> > > be removed in the future.
> > >
> > > * Implementation Outline
> > > We will implement the proposed changes by 1 phase.
> > > Phase 1
> > > 1. Collect pain points in using RocketMQ client APIs and redesign
> > > them.
> > > 2. Optimize those APIs.
> > > 3. Mark previous APIs deprecated.
> > >
> > >
> >
>