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 <lizhan...@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 <yangkun....@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 <yuz...@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....@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 <yuz...@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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
