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