[DISCUSS] About system usability improvements

[Goson zhang <go...@apache.org>]

Users who use TubeMQ for the first time will give feedback: it’s a bit
strange, why there are only a few CLI and very few HTTP interfaces?Why
should the metrics be output to a file? Why not like kafka, Broker can be
mounted to the system directly when it is started, and http direct access
can obtain a large amount of indicator information, why is it not in TubeMQ?

I think there are two reasons, one is the TubeMQ's design idea and the
other is the system stripping problem.

TubeMQ's design idea: TubeMQ is constructed in accordance with the SAAS
model, the designer considers that the cluster must be managed and the data
must be prevented from being translated to the counterfeited node; at the
same time, the magnitude of data processing is too large, frequent HTTP API
calls can directly affect system stability.

System stripping problem: we use third-party systems to avoid occupying the
resources of the Broker. such as CPU rate and disk capacity,we use
auxiliary systems for query data processing; the data metrics is output to
the file, and then through third-party statistics and then sent out for
processing, because the magnitude is beyond the ability of ordinary systems.

But ease of use is indeed a problem, so in any case, it is necessary to
provide as many ease of use tools as possible. So, in the near future, we
will improve this area, including how to produce and consume, and Broker,
Master expose more indicator data.

Wait, let's look at this effect after a period.

Re: [DISCUSS] About system usability improvements

[Goson zhang <go...@apache.org>]

In fact, I still hope that everyone can improve it together. Everyone’s
perspective is different, if you find an improvement, I hope you can pick
up the keyboard and put forward your ideas to make TubeMQ better.

Thanks

Lan Liang <li...@163.com> 于2020年12月27日周日 上午12:41写道：

> It's a good new, usability  is necessary. Thanks for your work, goson.
>
>
>
> Best Regards,
> Lan Liang
> On 12/23/2020 11:33，Goson zhang<go...@apache.org>
> <go...@apache.org> wrote：
>
> With in-depth analysis, we found that there are still many improvements
> needed to do in the existing web api implementation:
> some operations are simple query processing that does not require too much
> detailed information;
> some need to merge several apis into one api, which requires further
> further focus on functions.
>
> 0.8.0 version will continue to improve the ease of use of the web api
>
> Thanks
>
> Goson zhang <go...@apache.org> 于2020年12月1日周二 下午12:48写道：
>
> Users who use TubeMQ for the first time will give feedback: it’s a bit
> strange, why there are only a few CLI and very few HTTP interfaces?Why
> should the metrics be output to a file? Why not like kafka, Broker can be
> mounted to the system directly when it is started, and http direct access
> can obtain a large amount of indicator information, why is it not in
> TubeMQ?
>
> I think there are two reasons, one is the TubeMQ's design idea and the
> other is the system stripping problem.
>
> TubeMQ's design idea: TubeMQ is constructed in accordance with the SAAS
> model, the designer considers that the cluster must be managed and the data
> must be prevented from being translated to the counterfeited node; at the
> same time, the magnitude of data processing is too large, frequent HTTP API
> calls can directly affect system stability.
>
> System stripping problem: we use third-party systems to avoid occupying
> the resources of the Broker. such as CPU rate and disk capacity,we use
> auxiliary systems for query data processing; the data metrics is output to
> the file, and then through third-party statistics and then sent out for
> processing, because the magnitude is beyond the ability of ordinary
> systems.
>
> But ease of use is indeed a problem, so in any case, it is necessary to
> provide as many ease of use tools as possible. So, in the near future, we
> will improve this area, including how to produce and consume, and Broker,
> Master expose more indicator data.
>
> Wait, let's look at this effect after a period.
>
>

Re: [DISCUSS] About system usability improvements

[Lan Liang <li...@163.com>]

It's a good new, usability  is necessary. Thanks for your work, goson.






Best Regards,
Lan Liang
On 12/23/2020 11:33，Goson zhang<go...@apache.org> wrote：
With in-depth analysis, we found that there are still many improvements
needed to do in the existing web api implementation:
some operations are simple query processing that does not require too much
detailed information;
some need to merge several apis into one api, which requires further
further focus on functions.

0.8.0 version will continue to improve the ease of use of the web api

Thanks

Goson zhang <go...@apache.org> 于2020年12月1日周二 下午12:48写道：

Users who use TubeMQ for the first time will give feedback: it’s a bit
strange, why there are only a few CLI and very few HTTP interfaces?Why
should the metrics be output to a file? Why not like kafka, Broker can be
mounted to the system directly when it is started, and http direct access
can obtain a large amount of indicator information, why is it not in TubeMQ?

I think there are two reasons, one is the TubeMQ's design idea and the
other is the system stripping problem.

TubeMQ's design idea: TubeMQ is constructed in accordance with the SAAS
model, the designer considers that the cluster must be managed and the data
must be prevented from being translated to the counterfeited node; at the
same time, the magnitude of data processing is too large, frequent HTTP API
calls can directly affect system stability.

System stripping problem: we use third-party systems to avoid occupying
the resources of the Broker. such as CPU rate and disk capacity,we use
auxiliary systems for query data processing; the data metrics is output to
the file, and then through third-party statistics and then sent out for
processing, because the magnitude is beyond the ability of ordinary systems.

But ease of use is indeed a problem, so in any case, it is necessary to
provide as many ease of use tools as possible. So, in the near future, we
will improve this area, including how to produce and consume, and Broker,
Master expose more indicator data.

Wait, let's look at this effect after a period.

Re: [DISCUSS] About system usability improvements

[Goson zhang <go...@apache.org>]

With in-depth analysis, we found that there are still many improvements
needed to do in the existing web api implementation:
some operations are simple query processing that does not require too much
detailed information;
some need to merge several apis into one api, which requires further
further focus on functions.

0.8.0 version will continue to improve the ease of use of the web api

Thanks

Goson zhang <go...@apache.org> 于2020年12月1日周二 下午12:48写道：

> Users who use TubeMQ for the first time will give feedback: it’s a bit
> strange, why there are only a few CLI and very few HTTP interfaces?Why
> should the metrics be output to a file? Why not like kafka, Broker can be
> mounted to the system directly when it is started, and http direct access
> can obtain a large amount of indicator information, why is it not in TubeMQ?
>
> I think there are two reasons, one is the TubeMQ's design idea and the
> other is the system stripping problem.
>
> TubeMQ's design idea: TubeMQ is constructed in accordance with the SAAS
> model, the designer considers that the cluster must be managed and the data
> must be prevented from being translated to the counterfeited node; at the
> same time, the magnitude of data processing is too large, frequent HTTP API
> calls can directly affect system stability.
>
> System stripping problem: we use third-party systems to avoid occupying
> the resources of the Broker. such as CPU rate and disk capacity,we use
> auxiliary systems for query data processing; the data metrics is output to
> the file, and then through third-party statistics and then sent out for
> processing, because the magnitude is beyond the ability of ordinary systems.
>
> But ease of use is indeed a problem, so in any case, it is necessary to
> provide as many ease of use tools as possible. So, in the near future, we
> will improve this area, including how to produce and consume, and Broker,
> Master expose more indicator data.
>
> Wait, let's look at this effect after a period.
>