@zhuweilin Good question, and as you mentioned, Pullconsumer has higher complexity than pushConsumer at both the implementation and abstraction levels, so community classmates are still discussing it. If you have better suggestions, you can post them in this email.
[email protected] <[email protected]> 于2019年7月2日周二 下午5:09写道： > Hi, > > After going through the samples, I have a question about the > consumer. > There are 2 consumer demos, SimpleMQConsumer and SimpleOrderConsumer, > which are both push consumers. Is there any kind of pull consumer > available? > I remember that there is a pull consumer in rocketmq-openmessaging. > > Best Regards. > William > > > *From:* heng du <[email protected]> > *Date:* 2019-07-02 16:22 > *To:* users <[email protected]> > *Subject:* Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client > Hi, all, > > Thanks for providing great advice, and I’m happy to share a very > lightweight client that the community has contributed ( > https://github.com/apache/rocketmq-ons). > > Compared to previous clients, this SDK brings great ease of use, and just > as @wenfeng suggested that the new SDK removed the admin interfaces for > management. Moreover, the new SDK > hides the underlying implementation details and provides a minimal > configuration for quickly creating a client. > > Detailed usage can be found here: > https://github.com/apache/rocketmq-ons/tree/master/ons-sample. > > Best Regards. > Henry > > > wenfeng wang <[email protected]> 于2019年6月17日周一 下午8:22写道： > >> The current version of RocketMQ, maybe for code reusing (my >> understanding), the many admin implementations are included in the client >> package, and client package was encapsulated by admin. Which make a lot of >> additional complexity in the client package, and less clear semantics for >> the implementation. >> >> So, I think a separation of client and admin is necessary. About new >> admin command tools, I have a piece of advice we could build it in Go, Go >> Client project has implemented full RocketMQ Protocol, and Go can be >> compiled into an executable binary program of any platform. >> >> About API abstraction, I think we should hide the internal concepts and >> implementation details as much as possible, and avoid Override, which can >> reduce the learning cost of users, and improve the usability. In >> configuration, minimize configuration items and make the default >> configuration cover more scenarios as many as possible. >> >> 李澍 <[email protected]> 于2019年6月17日周一 上午10:51写道： >> >>> +1 >>> I'm happy to hear this, it's a good news for new users. >>> >>> >>> -----原始邮件----- >>> *发件人:*"zhong Malcolm" <[email protected]> >>> *发送时间:*2019-06-14 19:24:47 (星期五) >>> *收件人:* [email protected] >>> *抄送:* >>> *主题:* Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client >>> >>> 赞同 >>> >>> 徐江 <[email protected]> 于2019年6月11日周二 上午10:12写道： >>> >>>> good idea, for new users, they just want to use it work well very >>>> quickly, they want to see it can produce and consume success quickly, >>>> don't want to see so many parameters, so many APIs. >>>> >>>> >>>> At 2019-06-04 12:26:54, "heng du" <[email protected]> wrote: >>>> >>>> Dear RocketMQ Community, >>>> >>>> In order to enhance the usability of RocketMQ, a simple client API >>>> seems to be introduced into RocketMQ to further reduce the user threshold >>>> and lowering the probability of making mistakes. >>>> >>>> Compared With RocketMQ's origin client, the new client can be seen as a >>>> more high-level API that not only provides a better abstraction, but also >>>> removes some dangerous interfaces, hides more implementation details, and >>>> reduces A cumbersome configuration. At the same time, the original client >>>> will be retained as a low-level API to meet the additional needs of some >>>> experienced users, providing higher control ability for them. >>>> >>>> In the cloud-native era, messaging middleware improvements should not >>>> only be stayed in the use of cloud features (elasticity, scalability, >>>> etc.), but more importantly, it can provide users with a more concise and >>>> easy-to-use API to shield the difference brought by different cloud >>>> vendors or different deployment methods , so I think this should also be a >>>> focus of the follow-up development of RocketMQ. >>>> >>>> Looking forward to hearing your voice. >>>> >>>> Best Regards, >>>> Henry >>>> >>>> >>>> >>>> >>>> >>>
