On 07/19/2012 03:57 AM, Rafael Schloming wrote:
Recasting Proton as merely a component of Qpid and denying it its own mailing list might be seen as a way to preclude this possibility as it forces Proton users to be a subset of Qpid users and Proton goals to be subservient to Qpid goals.
This would be entirely wrong, but I don't think that argument is actually being made.
I haven't seen anyone that is not fully supportive of the fact that the proton library should be usable by any application (including higher level client libraries, brokers, bridges or end-user applications), and should explicitly not be constrained to a supporting role for the Qpid brokers or current client APIs.
Unfortunately this pretty much kills the whole point behind Proton, which is to make it as easy as possible for *everyone* to speak AMQP, not just for Qpid users to speak AMQP.
Absolutely, and to me that is entirely in line with Qpid's mission. We do not seek to have everyone use 'our' broker, or 'our' JMS client, or 'our' protocol engine for that matter. We seek to have people embrace AMQP so that an ecosystem grows that everyone benefits from.
Now of course we build things because we want them to be useful, so it is gratifying when people do use the components we build. But we aren't in the business of using one component to lure people in to use others against their will :-)
(Note that in the previous paragraph I'm using the term Qpid to refer to the existing Qpid brokers and clients, not some broader notion of a Qpid umbrella project.)
I think Qpid was formed as what you term an umbrella project, but at the time the nature of AMQP dictated the obvious components as being clients and brokers. Now the possibilities have expanded. What we do might change, why we are doing it - the mission - has not.
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
