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 <gst...@gmail.com>: > On Fri, Nov 4, 2016 at 4:26 PM, John D. Ament <john.d.am...@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
