Hi John,
That make sense, I agree the proposal should refine to less
competitive
but more focus on it's own design and architecture.
Would love to see that section to be updated before vote:-)
Thanks
Luke
Best Regards!
---------------------
Luke Han
On Sun, Nov 6, 2016 at 9:44 PM, John D. Ament <johndam...@apache.org> wrote:
> 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
> >
>
