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