You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by aaron ai <ya...@gmail.com> on 2022/03/06 08:10:55 UTC
[DISCUSS][RIP-37] New and unified APIs
Hi, RocketMQ Community：
Regarding the design of RocketMQ APIs, we have put forward some new ideas,
hoping to make the definition of messaging model and behavior more clear.
We have written the proposal and you can see it by the link below:
https://shimo.im/docs/m5kv92OeRRU8olqX
Please reply to this email if you have any suggestions.
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by aaron ai <ya...@gmail.com>.
Thanks for your attention, more details about the APIs would be revealed by
an independent pull request soon.
On Sun, Mar 6, 2022 at 7:59 PM Xiaorui Wang <vi...@apache.org> wrote:
> Great！I would like to view the details of API. Could you tell me where I
> can find it?
>
> Best regards,
>
> Xiaorui Wang 王小瑞
> Apache RocketMQ PMC chair
>
>
> On Sun, Mar 6, 2022 at 4:11 PM aaron ai <ya...@gmail.com> wrote:
>
> > Hi, RocketMQ Community：
> >
> > Regarding the design of RocketMQ APIs, we have put forward some new
> ideas,
> > hoping to make the definition of messaging model and behavior more clear.
> >
> > We have written the proposal and you can see it by the link below:
> > https://shimo.im/docs/m5kv92OeRRU8olqX
> >
> > Please reply to this email if you have any suggestions.
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by Xiaorui Wang <vi...@apache.org>.
Great！I would like to view the details of API. Could you tell me where I
can find it?
Best regards,
Xiaorui Wang 王小瑞
Apache RocketMQ PMC chair
On Sun, Mar 6, 2022 at 4:11 PM aaron ai <ya...@gmail.com> wrote:
> Hi, RocketMQ Community：
>
> Regarding the design of RocketMQ APIs, we have put forward some new ideas,
> hoping to make the definition of messaging model and behavior more clear.
>
> We have written the proposal and you can see it by the link below:
> https://shimo.im/docs/m5kv92OeRRU8olqX
>
> Please reply to this email if you have any suggestions.
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by Xiaorui Wang <vi...@apache.org>.
+1
Best regards,
Xiaorui Wang[1] - Apache RocketMQ PMC chair
[1] https://github.com/vintagewang
On Mon, Mar 14, 2022 at 2:34 PM 陈仲良 <ch...@gmail.com> wrote:
> +1, new APIs could reduce the difficulty of messaging development.
>
> Zhanhui Li <li...@apache.org> 于2022年3月14日周一 12:55写道：
>
> > +1
> >
> >
> > On Mon, Mar 14, 2022 at 10:53 AM yukon <yu...@apache.org> wrote:
> >
> > > +1, and let's start the further discussions on new APIs.
> > >
> > > On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com>
> wrote:
> > >
> > > > Hi, RocketMQ Community,
> > > >
> > > > As discussed in the previous email, we launched a new RIP to
> establish
> > > new
> > > > and unified APIs and it's time to start an email thread to enter the
> > > voting
> > > > process.
> > > >
> > > > links:
> > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > >
> > > > The vote will be open for at least 72 hours or until a necessary
> number
> > > of
> > > > votes are reached.
> > > >
> > > > Please vote accordingly:
> > > >
> > > > [ ] +1 approve
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove with the reason
> > > >
> > > >
> > > > Best Regards!
> > > >
> > > > On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> > > >
> > > > > Thanks, glad to see that weakly typed topic will keep exist.
> > > > >
> > > > > On 2022/03/10 08:01:46 yukon wrote:
> > > > > > Hi,
> > > > > >
> > > > > > A weakly typed topic that supports all kinds of messages has
> > > > > > many advantages, it's easy and flexible, while a strongly typed
> > topic
> > > > > also
> > > > > > has other advantages:
> > > > > >
> > > > > > 1. Reinforce the mind that rocketmq supports many integration
> > > patterns
> > > > > > which could simplify the development of business applications.
> > > > > > 2. Fail fast if developers send wrong typed messages to a
> strongly
> > > > typed
> > > > > > topic.
> > > > > > 3. Developers could arrange their applications by topics of
> > different
> > > > > > types, actually, it's a best practice of rocketmq
> > > > > > 4. RocketMQ has a chance to provide more competitive features for
> > > > > different
> > > > > > topic types separately.
> > > > > >
> > > > > > And, we won't disable the weakly typed topic, from an
> > implementation
> > > > > > perspective, we just add an attribute for the topic to indicate
> > > whether
> > > > > > it's a strongly typed topic, and a strongly typed topic can be
> > > > converted
> > > > > to
> > > > > > a weakly typed topic easily.
> > > > > >
> > > > > > Regards,
> > > > > > yukon
> > > > > >
> > > > > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Well, The new design about APIs allows us to focus more on the
> > > > feature
> > > > > > > itself, rather than the underlying implementation.
> > > > > > >
> > > > > > > It seems that topic type creates more limitations to users,
> > > actually
> > > > it
> > > > > > > simplifies operation of users, we think it is more friendly to
> > > users.
> > > > > > >
> > > > > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org>
> > wrote:
> > > > > > >
> > > > > > > > Hi, aaron:
> > > > > > > >
> > > > > > > > It is a great improvement, especially for some of features
> such
> > > as
> > > > > the
> > > > > > > new
> > > > > > > > constructor use
> > > > > > > > builder pattern, unified 3 kinds of consumers, unified
> > exception
> > > > > types,
> > > > > > > > transaction API
> > > > > > > > improvement.
> > > > > > > >
> > > > > > > > IMHO, many user scenarios have mixed message types, for
> > example,
> > > > > delay
> > > > > > > and
> > > > > > > > normal
> > > > > > > > message in the same topic, other cases use transaction and
> > normal
> > > > > message
> > > > > > > > in the same
> > > > > > > > topic. Do we have specail reason to split them into defferent
> > > > topics?
> > > > > > > >
> > > > > > > >
> > > > > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > > > > Hi, RocketMQ Community：
> > > > > > > > >
> > > > > > > > > Regarding the design of RocketMQ APIs, we have put forward
> > some
> > > > new
> > > > > > > > ideas,
> > > > > > > > > hoping to make the definition of messaging model and
> behavior
> > > > more
> > > > > > > clear.
> > > > > > > > >
> > > > > > > > > We have written the proposal and you can see it by the link
> > > > below:
> > > > > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > > > > >
> > > > > > > > > Please reply to this email if you have any suggestions.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by 陈仲良 <ch...@gmail.com>.
+1, new APIs could reduce the difficulty of messaging development.
Zhanhui Li <li...@apache.org> 于2022年3月14日周一 12:55写道：
> +1
>
>
> On Mon, Mar 14, 2022 at 10:53 AM yukon <yu...@apache.org> wrote:
>
> > +1, and let's start the further discussions on new APIs.
> >
> > On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com> wrote:
> >
> > > Hi, RocketMQ Community,
> > >
> > > As discussed in the previous email, we launched a new RIP to establish
> > new
> > > and unified APIs and it's time to start an email thread to enter the
> > voting
> > > process.
> > >
> > > links:
> > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > >
> > > The vote will be open for at least 72 hours or until a necessary number
> > of
> > > votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > >
> > > Best Regards!
> > >
> > > On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> > >
> > > > Thanks, glad to see that weakly typed topic will keep exist.
> > > >
> > > > On 2022/03/10 08:01:46 yukon wrote:
> > > > > Hi,
> > > > >
> > > > > A weakly typed topic that supports all kinds of messages has
> > > > > many advantages, it's easy and flexible, while a strongly typed
> topic
> > > > also
> > > > > has other advantages:
> > > > >
> > > > > 1. Reinforce the mind that rocketmq supports many integration
> > patterns
> > > > > which could simplify the development of business applications.
> > > > > 2. Fail fast if developers send wrong typed messages to a strongly
> > > typed
> > > > > topic.
> > > > > 3. Developers could arrange their applications by topics of
> different
> > > > > types, actually, it's a best practice of rocketmq
> > > > > 4. RocketMQ has a chance to provide more competitive features for
> > > > different
> > > > > topic types separately.
> > > > >
> > > > > And, we won't disable the weakly typed topic, from an
> implementation
> > > > > perspective, we just add an attribute for the topic to indicate
> > whether
> > > > > it's a strongly typed topic, and a strongly typed topic can be
> > > converted
> > > > to
> > > > > a weakly typed topic easily.
> > > > >
> > > > > Regards,
> > > > > yukon
> > > > >
> > > > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com>
> > wrote:
> > > > >
> > > > > > Well, The new design about APIs allows us to focus more on the
> > > feature
> > > > > > itself, rather than the underlying implementation.
> > > > > >
> > > > > > It seems that topic type creates more limitations to users,
> > actually
> > > it
> > > > > > simplifies operation of users, we think it is more friendly to
> > users.
> > > > > >
> > > > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org>
> wrote:
> > > > > >
> > > > > > > Hi, aaron:
> > > > > > >
> > > > > > > It is a great improvement, especially for some of features such
> > as
> > > > the
> > > > > > new
> > > > > > > constructor use
> > > > > > > builder pattern, unified 3 kinds of consumers, unified
> exception
> > > > types,
> > > > > > > transaction API
> > > > > > > improvement.
> > > > > > >
> > > > > > > IMHO, many user scenarios have mixed message types, for
> example,
> > > > delay
> > > > > > and
> > > > > > > normal
> > > > > > > message in the same topic, other cases use transaction and
> normal
> > > > message
> > > > > > > in the same
> > > > > > > topic. Do we have specail reason to split them into defferent
> > > topics?
> > > > > > >
> > > > > > >
> > > > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > > > Hi, RocketMQ Community：
> > > > > > > >
> > > > > > > > Regarding the design of RocketMQ APIs, we have put forward
> some
> > > new
> > > > > > > ideas,
> > > > > > > > hoping to make the definition of messaging model and behavior
> > > more
> > > > > > clear.
> > > > > > > >
> > > > > > > > We have written the proposal and you can see it by the link
> > > below:
> > > > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > > > >
> > > > > > > > Please reply to this email if you have any suggestions.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [VOTE][RIP-37] New and unified APIs
Posted by lollipop <lo...@apache.org>.
+1
On Mon, Mar 14, 2022 at 2:55 PM Rongtong Jin <ji...@mails.ucas.ac.cn>
wrote:
> +1
>
> "aaron ai" <yangkun.ayk@gmail.com>写道：
> > Hi, RocketMQ Community,
> >
> > As discussed in the previous email, we launched a new RIP to establish
> new
> > and unified APIs and it's time to start an email thread to enter the
> voting
> > process.
> >
> > links:
> > https://shimo.im/docs/m5kv92OeRRU8olqX
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Best Regards!
> >
> > On Mon, Mar 14, 2022 at 12:56 PM Zhanhui Li <li...@apache.org>
> wrote:
> >
> > > +1
> > >
> > >
> > > On Mon, Mar 14, 2022 at 10:53 AM yukon <yu...@apache.org> wrote:
> > >
> > > > +1, and let's start the further discussions on new APIs.
> > > >
> > > > On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com>
> wrote:
> > > >
> > > > > Hi, RocketMQ Community,
> > > > >
> > > > > As discussed in the previous email, we launched a new RIP to
> establish
> > > > new
> > > > > and unified APIs and it's time to start an email thread to enter
> the
> > > > voting
> > > > > process.
> > > > >
> > > > > links:
> > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > >
> > > > > The vote will be open for at least 72 hours or until a necessary
> number
> > > > of
> > > > > votes are reached.
> > > > >
> > > > > Please vote accordingly:
> > > > >
> > > > > [ ] +1 approve
> > > > > [ ] +0 no opinion
> > > > > [ ] -1 disapprove with the reason
> > > > >
> > > > >
> > > > > Best Regards!
> > > > >
> > > > > On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> > > > >
> > > > > > Thanks, glad to see that weakly typed topic will keep exist.
> > > > > >
> > > > > > On 2022/03/10 08:01:46 yukon wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > A weakly typed topic that supports all kinds of messages has
> > > > > > > many advantages, it's easy and flexible, while a strongly typed
> > > topic
> > > > > > also
> > > > > > > has other advantages:
> > > > > > >
> > > > > > > 1. Reinforce the mind that rocketmq supports many integration
> > > > patterns
> > > > > > > which could simplify the development of business applications.
> > > > > > > 2. Fail fast if developers send wrong typed messages to a
> strongly
> > > > > typed
> > > > > > > topic.
> > > > > > > 3. Developers could arrange their applications by topics of
> > > different
> > > > > > > types, actually, it's a best practice of rocketmq
> > > > > > > 4. RocketMQ has a chance to provide more competitive features
> for
> > > > > > different
> > > > > > > topic types separately.
> > > > > > >
> > > > > > > And, we won't disable the weakly typed topic, from an
> > > implementation
> > > > > > > perspective, we just add an attribute for the topic to indicate
> > > > whether
> > > > > > > it's a strongly typed topic, and a strongly typed topic can be
> > > > > converted
> > > > > > to
> > > > > > > a weakly typed topic easily.
> > > > > > >
> > > > > > > Regards,
> > > > > > > yukon
> > > > > > >
> > > > > > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <yangkun.ayk@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > > > Well, The new design about APIs allows us to focus more on
> the
> > > > > feature
> > > > > > > > itself, rather than the underlying implementation.
> > > > > > > >
> > > > > > > > It seems that topic type creates more limitations to users,
> > > > actually
> > > > > it
> > > > > > > > simplifies operation of users, we think it is more friendly
> to
> > > > users.
> > > > > > > >
> > > > > > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org>
> > > wrote:
> > > > > > > >
> > > > > > > > > Hi, aaron:
> > > > > > > > >
> > > > > > > > > It is a great improvement, especially for some of features
> such
> > > > as
> > > > > > the
> > > > > > > > new
> > > > > > > > > constructor use
> > > > > > > > > builder pattern, unified 3 kinds of consumers, unified
> > > exception
> > > > > > types,
> > > > > > > > > transaction API
> > > > > > > > > improvement.
> > > > > > > > >
> > > > > > > > > IMHO, many user scenarios have mixed message types, for
> > > example,
> > > > > > delay
> > > > > > > > and
> > > > > > > > > normal
> > > > > > > > > message in the same topic, other cases use transaction and
> > > normal
> > > > > > message
> > > > > > > > > in the same
> > > > > > > > > topic. Do we have specail reason to split them into
> defferent
> > > > > topics?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > > > > > Hi, RocketMQ Community：
> > > > > > > > > >
> > > > > > > > > > Regarding the design of RocketMQ APIs, we have put
> forward
> > > some
> > > > > new
> > > > > > > > > ideas,
> > > > > > > > > > hoping to make the definition of messaging model and
> behavior
> > > > > more
> > > > > > > > clear.
> > > > > > > > > >
> > > > > > > > > > We have written the proposal and you can see it by the
> link
> > > > > below:
> > > > > > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > > > > > >
> > > > > > > > > > Please reply to this email if you have any suggestions.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
Re: [VOTE][RIP-37] New and unified APIs
Posted by Rongtong Jin <ji...@mails.ucas.ac.cn>.
+1
"aaron ai" <yangkun.ayk@gmail.com>写道：
> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to establish new
> and unified APIs and it's time to start an email thread to enter the voting
> process.
>
> links:
> https://shimo.im/docs/m5kv92OeRRU8olqX
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
>
> On Mon, Mar 14, 2022 at 12:56 PM Zhanhui Li <li...@apache.org> wrote:
>
> > +1
> >
> >
> > On Mon, Mar 14, 2022 at 10:53 AM yukon <yu...@apache.org> wrote:
> >
> > > +1, and let's start the further discussions on new APIs.
> > >
> > > On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com> wrote:
> > >
> > > > Hi, RocketMQ Community,
> > > >
> > > > As discussed in the previous email, we launched a new RIP to establish
> > > new
> > > > and unified APIs and it's time to start an email thread to enter the
> > > voting
> > > > process.
> > > >
> > > > links:
> > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > >
> > > > The vote will be open for at least 72 hours or until a necessary number
> > > of
> > > > votes are reached.
> > > >
> > > > Please vote accordingly:
> > > >
> > > > [ ] +1 approve
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove with the reason
> > > >
> > > >
> > > > Best Regards!
> > > >
> > > > On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> > > >
> > > > > Thanks, glad to see that weakly typed topic will keep exist.
> > > > >
> > > > > On 2022/03/10 08:01:46 yukon wrote:
> > > > > > Hi,
> > > > > >
> > > > > > A weakly typed topic that supports all kinds of messages has
> > > > > > many advantages, it's easy and flexible, while a strongly typed
> > topic
> > > > > also
> > > > > > has other advantages:
> > > > > >
> > > > > > 1. Reinforce the mind that rocketmq supports many integration
> > > patterns
> > > > > > which could simplify the development of business applications.
> > > > > > 2. Fail fast if developers send wrong typed messages to a strongly
> > > > typed
> > > > > > topic.
> > > > > > 3. Developers could arrange their applications by topics of
> > different
> > > > > > types, actually, it's a best practice of rocketmq
> > > > > > 4. RocketMQ has a chance to provide more competitive features for
> > > > > different
> > > > > > topic types separately.
> > > > > >
> > > > > > And, we won't disable the weakly typed topic, from an
> > implementation
> > > > > > perspective, we just add an attribute for the topic to indicate
> > > whether
> > > > > > it's a strongly typed topic, and a strongly typed topic can be
> > > > converted
> > > > > to
> > > > > > a weakly typed topic easily.
> > > > > >
> > > > > > Regards,
> > > > > > yukon
> > > > > >
> > > > > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Well, The new design about APIs allows us to focus more on the
> > > > feature
> > > > > > > itself, rather than the underlying implementation.
> > > > > > >
> > > > > > > It seems that topic type creates more limitations to users,
> > > actually
> > > > it
> > > > > > > simplifies operation of users, we think it is more friendly to
> > > users.
> > > > > > >
> > > > > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org>
> > wrote:
> > > > > > >
> > > > > > > > Hi, aaron:
> > > > > > > >
> > > > > > > > It is a great improvement, especially for some of features such
> > > as
> > > > > the
> > > > > > > new
> > > > > > > > constructor use
> > > > > > > > builder pattern, unified 3 kinds of consumers, unified
> > exception
> > > > > types,
> > > > > > > > transaction API
> > > > > > > > improvement.
> > > > > > > >
> > > > > > > > IMHO, many user scenarios have mixed message types, for
> > example,
> > > > > delay
> > > > > > > and
> > > > > > > > normal
> > > > > > > > message in the same topic, other cases use transaction and
> > normal
> > > > > message
> > > > > > > > in the same
> > > > > > > > topic. Do we have specail reason to split them into defferent
> > > > topics?
> > > > > > > >
> > > > > > > >
> > > > > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > > > > Hi, RocketMQ Community：
> > > > > > > > >
> > > > > > > > > Regarding the design of RocketMQ APIs, we have put forward
> > some
> > > > new
> > > > > > > > ideas,
> > > > > > > > > hoping to make the definition of messaging model and behavior
> > > > more
> > > > > > > clear.
> > > > > > > > >
> > > > > > > > > We have written the proposal and you can see it by the link
> > > > below:
> > > > > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > > > > >
> > > > > > > > > Please reply to this email if you have any suggestions.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
[VOTE][RIP-37] New and unified APIs
Posted by aaron ai <ya...@gmail.com>.
Hi, RocketMQ Community,
As discussed in the previous email, we launched a new RIP to establish new
and unified APIs and it's time to start an email thread to enter the voting
process.
links:
https://shimo.im/docs/m5kv92OeRRU8olqX
The vote will be open for at least 72 hours or until a necessary number of
votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Best Regards!
On Mon, Mar 14, 2022 at 12:56 PM Zhanhui Li <li...@apache.org> wrote:
> +1
>
>
> On Mon, Mar 14, 2022 at 10:53 AM yukon <yu...@apache.org> wrote:
>
> > +1, and let's start the further discussions on new APIs.
> >
> > On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com> wrote:
> >
> > > Hi, RocketMQ Community,
> > >
> > > As discussed in the previous email, we launched a new RIP to establish
> > new
> > > and unified APIs and it's time to start an email thread to enter the
> > voting
> > > process.
> > >
> > > links:
> > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > >
> > > The vote will be open for at least 72 hours or until a necessary number
> > of
> > > votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > >
> > > Best Regards!
> > >
> > > On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> > >
> > > > Thanks, glad to see that weakly typed topic will keep exist.
> > > >
> > > > On 2022/03/10 08:01:46 yukon wrote:
> > > > > Hi,
> > > > >
> > > > > A weakly typed topic that supports all kinds of messages has
> > > > > many advantages, it's easy and flexible, while a strongly typed
> topic
> > > > also
> > > > > has other advantages:
> > > > >
> > > > > 1. Reinforce the mind that rocketmq supports many integration
> > patterns
> > > > > which could simplify the development of business applications.
> > > > > 2. Fail fast if developers send wrong typed messages to a strongly
> > > typed
> > > > > topic.
> > > > > 3. Developers could arrange their applications by topics of
> different
> > > > > types, actually, it's a best practice of rocketmq
> > > > > 4. RocketMQ has a chance to provide more competitive features for
> > > > different
> > > > > topic types separately.
> > > > >
> > > > > And, we won't disable the weakly typed topic, from an
> implementation
> > > > > perspective, we just add an attribute for the topic to indicate
> > whether
> > > > > it's a strongly typed topic, and a strongly typed topic can be
> > > converted
> > > > to
> > > > > a weakly typed topic easily.
> > > > >
> > > > > Regards,
> > > > > yukon
> > > > >
> > > > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com>
> > wrote:
> > > > >
> > > > > > Well, The new design about APIs allows us to focus more on the
> > > feature
> > > > > > itself, rather than the underlying implementation.
> > > > > >
> > > > > > It seems that topic type creates more limitations to users,
> > actually
> > > it
> > > > > > simplifies operation of users, we think it is more friendly to
> > users.
> > > > > >
> > > > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org>
> wrote:
> > > > > >
> > > > > > > Hi, aaron:
> > > > > > >
> > > > > > > It is a great improvement, especially for some of features such
> > as
> > > > the
> > > > > > new
> > > > > > > constructor use
> > > > > > > builder pattern, unified 3 kinds of consumers, unified
> exception
> > > > types,
> > > > > > > transaction API
> > > > > > > improvement.
> > > > > > >
> > > > > > > IMHO, many user scenarios have mixed message types, for
> example,
> > > > delay
> > > > > > and
> > > > > > > normal
> > > > > > > message in the same topic, other cases use transaction and
> normal
> > > > message
> > > > > > > in the same
> > > > > > > topic. Do we have specail reason to split them into defferent
> > > topics?
> > > > > > >
> > > > > > >
> > > > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > > > Hi, RocketMQ Community：
> > > > > > > >
> > > > > > > > Regarding the design of RocketMQ APIs, we have put forward
> some
> > > new
> > > > > > > ideas,
> > > > > > > > hoping to make the definition of messaging model and behavior
> > > more
> > > > > > clear.
> > > > > > > >
> > > > > > > > We have written the proposal and you can see it by the link
> > > below:
> > > > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > > > >
> > > > > > > > Please reply to this email if you have any suggestions.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by Zhanhui Li <li...@apache.org>.
+1
On Mon, Mar 14, 2022 at 10:53 AM yukon <yu...@apache.org> wrote:
> +1, and let's start the further discussions on new APIs.
>
> On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com> wrote:
>
> > Hi, RocketMQ Community,
> >
> > As discussed in the previous email, we launched a new RIP to establish
> new
> > and unified APIs and it's time to start an email thread to enter the
> voting
> > process.
> >
> > links:
> > https://shimo.im/docs/m5kv92OeRRU8olqX
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Best Regards!
> >
> > On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> >
> > > Thanks, glad to see that weakly typed topic will keep exist.
> > >
> > > On 2022/03/10 08:01:46 yukon wrote:
> > > > Hi,
> > > >
> > > > A weakly typed topic that supports all kinds of messages has
> > > > many advantages, it's easy and flexible, while a strongly typed topic
> > > also
> > > > has other advantages:
> > > >
> > > > 1. Reinforce the mind that rocketmq supports many integration
> patterns
> > > > which could simplify the development of business applications.
> > > > 2. Fail fast if developers send wrong typed messages to a strongly
> > typed
> > > > topic.
> > > > 3. Developers could arrange their applications by topics of different
> > > > types, actually, it's a best practice of rocketmq
> > > > 4. RocketMQ has a chance to provide more competitive features for
> > > different
> > > > topic types separately.
> > > >
> > > > And, we won't disable the weakly typed topic, from an implementation
> > > > perspective, we just add an attribute for the topic to indicate
> whether
> > > > it's a strongly typed topic, and a strongly typed topic can be
> > converted
> > > to
> > > > a weakly typed topic easily.
> > > >
> > > > Regards,
> > > > yukon
> > > >
> > > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com>
> wrote:
> > > >
> > > > > Well, The new design about APIs allows us to focus more on the
> > feature
> > > > > itself, rather than the underlying implementation.
> > > > >
> > > > > It seems that topic type creates more limitations to users,
> actually
> > it
> > > > > simplifies operation of users, we think it is more friendly to
> users.
> > > > >
> > > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
> > > > >
> > > > > > Hi, aaron:
> > > > > >
> > > > > > It is a great improvement, especially for some of features such
> as
> > > the
> > > > > new
> > > > > > constructor use
> > > > > > builder pattern, unified 3 kinds of consumers, unified exception
> > > types,
> > > > > > transaction API
> > > > > > improvement.
> > > > > >
> > > > > > IMHO, many user scenarios have mixed message types, for example,
> > > delay
> > > > > and
> > > > > > normal
> > > > > > message in the same topic, other cases use transaction and normal
> > > message
> > > > > > in the same
> > > > > > topic. Do we have specail reason to split them into defferent
> > topics?
> > > > > >
> > > > > >
> > > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > > Hi, RocketMQ Community：
> > > > > > >
> > > > > > > Regarding the design of RocketMQ APIs, we have put forward some
> > new
> > > > > > ideas,
> > > > > > > hoping to make the definition of messaging model and behavior
> > more
> > > > > clear.
> > > > > > >
> > > > > > > We have written the proposal and you can see it by the link
> > below:
> > > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > > >
> > > > > > > Please reply to this email if you have any suggestions.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by yukon <yu...@apache.org>.
+1, and let's start the further discussions on new APIs.
On Mon, Mar 14, 2022 at 10:32 AM aaron ai <ya...@gmail.com> wrote:
> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to establish new
> and unified APIs and it's time to start an email thread to enter the voting
> process.
>
> links:
> https://shimo.im/docs/m5kv92OeRRU8olqX
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
>
> On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
>
> > Thanks, glad to see that weakly typed topic will keep exist.
> >
> > On 2022/03/10 08:01:46 yukon wrote:
> > > Hi,
> > >
> > > A weakly typed topic that supports all kinds of messages has
> > > many advantages, it's easy and flexible, while a strongly typed topic
> > also
> > > has other advantages:
> > >
> > > 1. Reinforce the mind that rocketmq supports many integration patterns
> > > which could simplify the development of business applications.
> > > 2. Fail fast if developers send wrong typed messages to a strongly
> typed
> > > topic.
> > > 3. Developers could arrange their applications by topics of different
> > > types, actually, it's a best practice of rocketmq
> > > 4. RocketMQ has a chance to provide more competitive features for
> > different
> > > topic types separately.
> > >
> > > And, we won't disable the weakly typed topic, from an implementation
> > > perspective, we just add an attribute for the topic to indicate whether
> > > it's a strongly typed topic, and a strongly typed topic can be
> converted
> > to
> > > a weakly typed topic easily.
> > >
> > > Regards,
> > > yukon
> > >
> > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com> wrote:
> > >
> > > > Well, The new design about APIs allows us to focus more on the
> feature
> > > > itself, rather than the underlying implementation.
> > > >
> > > > It seems that topic type creates more limitations to users, actually
> it
> > > > simplifies operation of users, we think it is more friendly to users.
> > > >
> > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
> > > >
> > > > > Hi, aaron:
> > > > >
> > > > > It is a great improvement, especially for some of features such as
> > the
> > > > new
> > > > > constructor use
> > > > > builder pattern, unified 3 kinds of consumers, unified exception
> > types,
> > > > > transaction API
> > > > > improvement.
> > > > >
> > > > > IMHO, many user scenarios have mixed message types, for example,
> > delay
> > > > and
> > > > > normal
> > > > > message in the same topic, other cases use transaction and normal
> > message
> > > > > in the same
> > > > > topic. Do we have specail reason to split them into defferent
> topics?
> > > > >
> > > > >
> > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > Hi, RocketMQ Community：
> > > > > >
> > > > > > Regarding the design of RocketMQ APIs, we have put forward some
> new
> > > > > ideas,
> > > > > > hoping to make the definition of messaging model and behavior
> more
> > > > clear.
> > > > > >
> > > > > > We have written the proposal and you can see it by the link
> below:
> > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > >
> > > > > > Please reply to this email if you have any suggestions.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by aaron ai <ya...@gmail.com>.
Hi, RocketMQ Community,
As discussed in the previous email, we launched a new RIP to establish new
and unified APIs and it's time to start an email thread to enter the voting
process.
links:
https://shimo.im/docs/m5kv92OeRRU8olqX
The vote will be open for at least 72 hours or until a necessary number of
votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Best Regards!
On Sat, Mar 12, 2022 at 2:32 PM yuzhou <yu...@apache.org> wrote:
> Thanks, glad to see that weakly typed topic will keep exist.
>
> On 2022/03/10 08:01:46 yukon wrote:
> > Hi,
> >
> > A weakly typed topic that supports all kinds of messages has
> > many advantages, it's easy and flexible, while a strongly typed topic
> also
> > has other advantages:
> >
> > 1. Reinforce the mind that rocketmq supports many integration patterns
> > which could simplify the development of business applications.
> > 2. Fail fast if developers send wrong typed messages to a strongly typed
> > topic.
> > 3. Developers could arrange their applications by topics of different
> > types, actually, it's a best practice of rocketmq
> > 4. RocketMQ has a chance to provide more competitive features for
> different
> > topic types separately.
> >
> > And, we won't disable the weakly typed topic, from an implementation
> > perspective, we just add an attribute for the topic to indicate whether
> > it's a strongly typed topic, and a strongly typed topic can be converted
> to
> > a weakly typed topic easily.
> >
> > Regards,
> > yukon
> >
> > On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com> wrote:
> >
> > > Well, The new design about APIs allows us to focus more on the feature
> > > itself, rather than the underlying implementation.
> > >
> > > It seems that topic type creates more limitations to users, actually it
> > > simplifies operation of users, we think it is more friendly to users.
> > >
> > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
> > >
> > > > Hi, aaron:
> > > >
> > > > It is a great improvement, especially for some of features such as
> the
> > > new
> > > > constructor use
> > > > builder pattern, unified 3 kinds of consumers, unified exception
> types,
> > > > transaction API
> > > > improvement.
> > > >
> > > > IMHO, many user scenarios have mixed message types, for example,
> delay
> > > and
> > > > normal
> > > > message in the same topic, other cases use transaction and normal
> message
> > > > in the same
> > > > topic. Do we have specail reason to split them into defferent topics?
> > > >
> > > >
> > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > Hi, RocketMQ Community：
> > > > >
> > > > > Regarding the design of RocketMQ APIs, we have put forward some new
> > > > ideas,
> > > > > hoping to make the definition of messaging model and behavior more
> > > clear.
> > > > >
> > > > > We have written the proposal and you can see it by the link below:
> > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > >
> > > > > Please reply to this email if you have any suggestions.
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by yuzhou <yu...@apache.org>.
Thanks, glad to see that weakly typed topic will keep exist.
On 2022/03/10 08:01:46 yukon wrote:
> Hi,
>
> A weakly typed topic that supports all kinds of messages has
> many advantages, it's easy and flexible, while a strongly typed topic also
> has other advantages:
>
> 1. Reinforce the mind that rocketmq supports many integration patterns
> which could simplify the development of business applications.
> 2. Fail fast if developers send wrong typed messages to a strongly typed
> topic.
> 3. Developers could arrange their applications by topics of different
> types, actually, it's a best practice of rocketmq
> 4. RocketMQ has a chance to provide more competitive features for different
> topic types separately.
>
> And, we won't disable the weakly typed topic, from an implementation
> perspective, we just add an attribute for the topic to indicate whether
> it's a strongly typed topic, and a strongly typed topic can be converted to
> a weakly typed topic easily.
>
> Regards,
> yukon
>
> On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com> wrote:
>
> > Well, The new design about APIs allows us to focus more on the feature
> > itself, rather than the underlying implementation.
> >
> > It seems that topic type creates more limitations to users, actually it
> > simplifies operation of users, we think it is more friendly to users.
> >
> > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
> >
> > > Hi, aaron:
> > >
> > > It is a great improvement, especially for some of features such as the
> > new
> > > constructor use
> > > builder pattern, unified 3 kinds of consumers, unified exception types,
> > > transaction API
> > > improvement.
> > >
> > > IMHO, many user scenarios have mixed message types, for example, delay
> > and
> > > normal
> > > message in the same topic, other cases use transaction and normal message
> > > in the same
> > > topic. Do we have specail reason to split them into defferent topics?
> > >
> > >
> > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > Hi, RocketMQ Community：
> > > >
> > > > Regarding the design of RocketMQ APIs, we have put forward some new
> > > ideas,
> > > > hoping to make the definition of messaging model and behavior more
> > clear.
> > > >
> > > > We have written the proposal and you can see it by the link below:
> > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > >
> > > > Please reply to this email if you have any suggestions.
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by aaron ai <ya...@gmail.com>.
Maybe SimpleConsumer is a better name instead of PopConsumer.
On Thu, Mar 10, 2022 at 4:02 PM yukon <yu...@apache.org> wrote:
> Hi,
>
> A weakly typed topic that supports all kinds of messages has
> many advantages, it's easy and flexible, while a strongly typed topic also
> has other advantages:
>
> 1. Reinforce the mind that rocketmq supports many integration patterns
> which could simplify the development of business applications.
> 2. Fail fast if developers send wrong typed messages to a strongly typed
> topic.
> 3. Developers could arrange their applications by topics of different
> types, actually, it's a best practice of rocketmq
> 4. RocketMQ has a chance to provide more competitive features for different
> topic types separately.
>
> And, we won't disable the weakly typed topic, from an implementation
> perspective, we just add an attribute for the topic to indicate whether
> it's a strongly typed topic, and a strongly typed topic can be converted to
> a weakly typed topic easily.
>
> Regards,
> yukon
>
> On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com> wrote:
>
> > Well, The new design about APIs allows us to focus more on the feature
> > itself, rather than the underlying implementation.
> >
> > It seems that topic type creates more limitations to users, actually it
> > simplifies operation of users, we think it is more friendly to users.
> >
> > On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
> >
> > > Hi, aaron:
> > >
> > > It is a great improvement, especially for some of features such as the
> > new
> > > constructor use
> > > builder pattern, unified 3 kinds of consumers, unified exception types,
> > > transaction API
> > > improvement.
> > >
> > > IMHO, many user scenarios have mixed message types, for example, delay
> > and
> > > normal
> > > message in the same topic, other cases use transaction and normal
> message
> > > in the same
> > > topic. Do we have specail reason to split them into defferent topics?
> > >
> > >
> > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > Hi, RocketMQ Community：
> > > >
> > > > Regarding the design of RocketMQ APIs, we have put forward some new
> > > ideas,
> > > > hoping to make the definition of messaging model and behavior more
> > clear.
> > > >
> > > > We have written the proposal and you can see it by the link below:
> > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > >
> > > > Please reply to this email if you have any suggestions.
> > > >
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by yukon <yu...@apache.org>.
Hi,
A weakly typed topic that supports all kinds of messages has
many advantages, it's easy and flexible, while a strongly typed topic also
has other advantages:
1. Reinforce the mind that rocketmq supports many integration patterns
which could simplify the development of business applications.
2. Fail fast if developers send wrong typed messages to a strongly typed
topic.
3. Developers could arrange their applications by topics of different
types, actually, it's a best practice of rocketmq
4. RocketMQ has a chance to provide more competitive features for different
topic types separately.
And, we won't disable the weakly typed topic, from an implementation
perspective, we just add an attribute for the topic to indicate whether
it's a strongly typed topic, and a strongly typed topic can be converted to
a weakly typed topic easily.
Regards,
yukon
On Mon, Mar 7, 2022 at 2:04 PM aaron ai <ya...@gmail.com> wrote:
> Well, The new design about APIs allows us to focus more on the feature
> itself, rather than the underlying implementation.
>
> It seems that topic type creates more limitations to users, actually it
> simplifies operation of users, we think it is more friendly to users.
>
> On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
>
> > Hi, aaron:
> >
> > It is a great improvement, especially for some of features such as the
> new
> > constructor use
> > builder pattern, unified 3 kinds of consumers, unified exception types,
> > transaction API
> > improvement.
> >
> > IMHO, many user scenarios have mixed message types, for example, delay
> and
> > normal
> > message in the same topic, other cases use transaction and normal message
> > in the same
> > topic. Do we have specail reason to split them into defferent topics?
> >
> >
> > On 2022/03/06 08:10:55 aaron ai wrote:
> > > Hi, RocketMQ Community：
> > >
> > > Regarding the design of RocketMQ APIs, we have put forward some new
> > ideas,
> > > hoping to make the definition of messaging model and behavior more
> clear.
> > >
> > > We have written the proposal and you can see it by the link below:
> > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > >
> > > Please reply to this email if you have any suggestions.
> > >
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by aaron ai <ya...@gmail.com>.
Well, The new design about APIs allows us to focus more on the feature
itself, rather than the underlying implementation.
It seems that topic type creates more limitations to users, actually it
simplifies operation of users, we think it is more friendly to users.
On Mon, Mar 7, 2022 at 10:59 AM yuzhou <yu...@apache.org> wrote:
> Hi, aaron:
>
> It is a great improvement, especially for some of features such as the new
> constructor use
> builder pattern, unified 3 kinds of consumers, unified exception types,
> transaction API
> improvement.
>
> IMHO, many user scenarios have mixed message types, for example, delay and
> normal
> message in the same topic, other cases use transaction and normal message
> in the same
> topic. Do we have specail reason to split them into defferent topics?
>
>
> On 2022/03/06 08:10:55 aaron ai wrote:
> > Hi, RocketMQ Community：
> >
> > Regarding the design of RocketMQ APIs, we have put forward some new
> ideas,
> > hoping to make the definition of messaging model and behavior more clear.
> >
> > We have written the proposal and you can see it by the link below:
> > https://shimo.im/docs/m5kv92OeRRU8olqX
> >
> > Please reply to this email if you have any suggestions.
> >
>
Re: [DISCUSS][RIP-37] New and unified APIs
Posted by yuzhou <yu...@apache.org>.
Hi, aaron:
It is a great improvement, especially for some of features such as the new constructor use
builder pattern, unified 3 kinds of consumers, unified exception types, transaction API
improvement.
IMHO, many user scenarios have mixed message types, for example, delay and normal
message in the same topic, other cases use transaction and normal message in the same
topic. Do we have specail reason to split them into defferent topics?
On 2022/03/06 08:10:55 aaron ai wrote:
> Hi, RocketMQ Community：
>
> Regarding the design of RocketMQ APIs, we have put forward some new ideas,
> hoping to make the definition of messaging model and behavior more clear.
>
> We have written the proposal and you can see it by the link below:
> https://shimo.im/docs/m5kv92OeRRU8olqX
>
> Please reply to this email if you have any suggestions.
>