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