You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@rocketmq.apache.org by heng du <du...@gmail.com> on 2019/06/04 04:26:54 UTC
[DISCUSS]Introduce a lightweight Apache RocketMQ client
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
Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by Zhanhui Li <li...@gmail.com>.
Looks it is the right direction to go. A simplified and unified set of API does lower the bar for new users in the community.
> 在 2019年6月4日，下午12:26，heng du <du...@gmail.com> 写道：
>
> 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
Re: Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by heng du <du...@gmail.com>.
@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.
zhuweilin@iie.ac.cn <zh...@iie.ac.cn> 于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 <du...@gmail.com>
> *Date:* 2019-07-02 16:22
> *To:* users <us...@rocketmq.apache.org>
> *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 <sx...@gmail.com> 于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.
>>
>> 李澍 <li...@fiberhome.com> 于2019年6月17日周一 上午10:51写道：
>>
>>> +1
>>> I'm happy to hear this, it's a good news for new users.
>>>
>>>
>>> -----原始邮件-----
>>> *发件人:*"zhong Malcolm" <zz...@gmail.com>
>>> *发送时间:*2019-06-14 19:24:47 (星期五)
>>> *收件人:* users@rocketmq.apache.org
>>> *抄送:*
>>> *主题:* Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
>>>
>>> 赞同
>>>
>>> 徐江 <jo...@163.com> 于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" <du...@gmail.com> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
Re: Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by "zhuweilin@iie.ac.cn" <zh...@iie.ac.cn>.
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
Date: 2019-07-02 16:22
To: users
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 <sx...@gmail.com> 于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.
李澍 <li...@fiberhome.com> 于2019年6月17日周一 上午10:51写道：
+1
I'm happy to hear this, it's a good news for new users.
-----原始邮件-----
发件人:"zhong Malcolm" <zz...@gmail.com>
发送时间:2019-06-14 19:24:47 (星期五)
收件人: users@rocketmq.apache.org
抄送:
主题: Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
赞同
徐江 <jo...@163.com> 于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" <du...@gmail.com> 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
Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by heng du <du...@gmail.com>.
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 <sx...@gmail.com> 于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.
>
> 李澍 <li...@fiberhome.com> 于2019年6月17日周一 上午10:51写道：
>
>> +1
>> I'm happy to hear this, it's a good news for new users.
>>
>>
>> -----原始邮件-----
>> *发件人:*"zhong Malcolm" <zz...@gmail.com>
>> *发送时间:*2019-06-14 19:24:47 (星期五)
>> *收件人:* users@rocketmq.apache.org
>> *抄送:*
>> *主题:* Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
>>
>> 赞同
>>
>> 徐江 <jo...@163.com> 于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" <du...@gmail.com> 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
>>>
>>>
>>>
>>>
>>>
>>
Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by wenfeng wang <sx...@gmail.com>.
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.
李澍 <li...@fiberhome.com> 于2019年6月17日周一 上午10:51写道：
> +1
> I'm happy to hear this, it's a good news for new users.
>
>
> -----原始邮件-----
> *发件人:*"zhong Malcolm" <zz...@gmail.com>
> *发送时间:*2019-06-14 19:24:47 (星期五)
> *收件人:* users@rocketmq.apache.org
> *抄送:*
> *主题:* Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
>
> 赞同
>
> 徐江 <jo...@163.com> 于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" <du...@gmail.com> 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
>>
>>
>>
>>
>>
>
Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by 李澍 <li...@fiberhome.com>.
+1
I'm happy to hear this, it's a good news for new users.
-----原始邮件-----
发件人:"zhong Malcolm" <zz...@gmail.com>
发送时间:2019-06-14 19:24:47 (星期五)
收件人: users@rocketmq.apache.org
抄送:
主题: Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
赞同
徐江 <jo...@163.com> 于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" <du...@gmail.com> 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
Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by zhong Malcolm <zz...@gmail.com>.
赞同
徐江 <jo...@163.com> 于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" <du...@gmail.com> 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
>
>
>
>
>
Re:[DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by 徐江 <jo...@163.com>.
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" <du...@gmail.com> 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
Re: [DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by Zhanhui Li <li...@gmail.com>.
Looks it is the right direction to go. A simplified and unified set of API does lower the bar for new users in the community.
> 在 2019年6月4日，下午12:26，heng du <du...@gmail.com> 写道：
>
> 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
Re:[DISCUSS]Introduce a lightweight Apache RocketMQ client
Posted by 徐江 <jo...@163.com>.
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" <du...@gmail.com> 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