[RESULT] [VOTE] [RIP-37] New and Unified APIs

[aaron ai <ya...@gmail.com>]

Hello RocketMQ Community,

This is the vote result for the kickoff of RIP-37 《New and Unified APIs》,
and it has
been passed with [5] binding +1s, [1] non-binding:

*Binding votes +1s:*

yukon(yukon@apache.org)
lollipopjin(lollipop@apache.org)
Zhanhui Li(lizhanhui@apache.org)
Rongtong Jin(jinrongtong16@mails.ucas.ac.cn)
Xiaorui Wang(vintagewang@apache.org)

*Non-binding votes +1s:*

chenzlalvin (chenzl92@gmail.com)


This RIP will be accepted and its status will be updated to RocketMQ wiki
soon.


Thanks.

On Mon, Mar 14, 2022 at 2:33 PM 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 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.
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>