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. > > > > > > > > > > > > > > >
