Luke, Von, thanks for the responses. Some more comments in line.
On Sun, Nov 6, 2016 at 7:48 AM vongosling <fengji...@gmail.com> wrote: > 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~ > I think I get it now. Please update the proposal to note that Alibaba provides a service named ONS that is derived from RocketMQ. > > > 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~ > > I think maybe take a look again at the response sent to Bruce yesterday. I want to make sure you're understanding the concern I have. Greg said it best - Apache products do not compete with one another. I specifically want to see the "Relationships with Other Apache Products" section updated to focus on the consuming relationships, and limit the competitive aspects of it. These questions were simply leading questions to try to give you some ideas of what you could put in that section. John > > 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 >
