On 07/19/2012 01:23 PM, Rafael Schloming wrote:
The fundamental issue is that there are at least two ways to promote
adoption of AMQP: either via competition, e.g. building a broker that
happens to speak AMQP and competes with existing brokers; or via
cooperation, e.g. building a library to make it easy for any existing
broker to speak AMQP.
I don't accept that view.
I believe our mission is to provide useful components under an ASF
license, developed through an ASF governed process in order to ensure
that there is truly open, freely usable AMQP infrastructure for anyone
who wants it.
I don't accept that based on which component I help to develop I am
choosing between cooperation and competition. I believe in all
components I would be choosing collaboration and committing to
interoperability.
While both of these fall under the very broad remit of promoting
adoption of AMQP, it simply doesn't work to mix the two strategies
within the same project with no delineation.
I think the components are very clearly delineated. That was the whole
purpose of the proposed svn structure that is now in place.
As we have commented on already, there is some overlap in role between
the existing qpid messaging API and the evolving proton APIs. It makes
sense to continue to explore that and hopefully reach a resolution that
serves the interests of all users.
If you do you're
essentially asking people to embed their competitor's component into
their broker so that their users can more easily migrate over to the
competition.
I disagree. Were that argument true it would undermine the premise of
AMQP in my view. AMQP allows me to take one component from one source
and having it work together with another component from another source.
Picking a Qpid client does not require you to pick a Qpid broker and
vice versa.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
