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([email protected]) lollipopjin([email protected]) Zhanhui Li([email protected]) Rongtong Jin([email protected]) Xiaorui Wang([email protected]) *Non-binding votes +1s:* chenzlalvin ([email protected]) 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 <[email protected]> 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 <[email protected]> wrote: > >> +1 >> >> >> On Mon, Mar 14, 2022 at 10:53 AM yukon <[email protected]> wrote: >> >> > +1, and let's start the further discussions on new APIs. >> > >> > On Mon, Mar 14, 2022 at 10:32 AM aaron ai <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >> > 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 <[email protected]> >> 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. >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
