incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vongosling <fengji...@gmail.com>
Subject Re: [DISCUSS] RocketMQ Incubation Proposal
Date Sun, 06 Nov 2016 12:48:00 GMT
Hi, john:

Thank you providing AsterixDB proposal, so as to help our complement our
proposal. Or to say, give us some advice for RocketMQ community development
roadmap~

Next, let me clarify some question we have talked about.


1. About ONS and RocketMQ relationship~

ONS is our Cloud Messaging Service, you also think it as our internal
messaging name. But it is built base on RocketMQ, adding some extra
features mainly associated with security, audit, web console, etc...  Have
I made everything clear to you. If not, I can depict it using some
pictures~


2. How can RocketMQ work with the existing Kafka or ActiveMQ communities to
build cross platform clients?

IMO, excellent products, They must have a common feature. That is its
pluggable mechanism. We can use it, just like i have said in the latest
reply(we are developing kafka-proxy this product, in the near future, we
hope to invite kafka guys to make a technical exchange). We can use this
idea to integrate RocketMQ with Kafka and ActiveMQ ecosystem seamlessly.

In addition, we are planning to draft some messaging specification.we want
it absorb the advantage of the existing Corbar‘s Notification Service
Specification, JMS, AMQP, MQTT and other text protocol.It not include API
layer standard, but also possess wireless protocol advantage. May be it
will experience a long time to discuss. But If an agreement is reached, may
be, no matter Kafka, ActiveMQ, RocketMQ or other MQ products, there was no
doubting that cross platform client is not a difficult thing because our
common cross-platform protocol.

3. How can RocketMQ look to leverage Cassandra, Geode, Derby as backend
persistence stores?

As I have said, nowadays, RocketMQ storage is custom-built for low-latency
purpose. It just use JDK primitive FIle API and some JNI tech..
In the next step, if we hope to leverage Cassandra, Geode, Derby or other
full-blown product, we must research them intensively, knowing about and
make sure they are suitable for our low latency design goal. At the same
time, we also abstract our storage layer(you can think it as SPI), let it
meet adaptor design pattern(We will also make use of JDK's service locator
pattern to support our storage SPI ). All these are in ready, many concrete
implementation adapter can be created, may be by RocketMQ project guys, may
be contributed by community enthusiast. if latter way, we must give some
guidance and help for them. The guidance seems like this
https://github.com/alibaba/RocketMQ/wiki/multi-language-sdk.


Last, Thanks again every apache guys(Especially Bruce, Brian, Ross, John,
Roman, Greg, Jim etc... )magnanimous diverse culture. We have reasons to
believe that Apache is the most suitable home as an open source project
following an established development model. We are always willing to lend
an ear to the apache and communities, making our product ecosystem towards
a more healthy and more active direction~


Best Regards ~

Von Gosling


2016-11-06 17:20 GMT+08:00 Greg Stein <gstein@gmail.com>:

> On Fri, Nov 4, 2016 at 4:26 PM, John D. Ament <john.d.ament@gmail.com>
> wrote:
> >...
>
> > I'm still a bit leary about the "relationship with other apache products"
> > section still.  I'm not interested in seeing how a podling competes with
> > other projects
>
>
> Apache projects don't "compete" with anybody. The source code is *offered*
> to the public.
>
> As a 501(c)(3), we're specifically disallowed from competing with
> commercial organizations. But even within the ASF and other open source
> projects, the ASF is simply providing a home for communities to organize,
> to grow, to construct software for the public. At its most base level, the
> Foundation doesn't care what the project does, how "successful" it is (by
> whatever metric), or if ten of its communities all produce software to do
> the same thing. Each community might have a different thought, a different
> approach, or even something as minor as a different view on release cycles.
>
> All communities are welcome.
>
> Cheers,
> -g
>



-- 
Nothing is impossible

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message