On 10/10/2013 09:38 AM, Rob Godfrey wrote:
My main concern is that I believe that Qpid should be primarily directed at
implementing AMQP standards, and building resuable toolkits and components
that fit into any AMQP network. I'd be very concerned if we were inventing
alternative management protocols, or building components that only
interoperated with other Qpid tools.
So, personally I'd like to see statement around components saying that they
will be fully implementing emerging AMQP Management, AMQP addressing, etc.
standards, and that we as a project then ensure we stick to these goals.
Interoperability with other AMQP compliant components both in and out of
Qpid and Apache is certainly key. That is what AMQP is all about and
what Qpid should be about.
Faithful implementation of the existing AMQP specification is clearly a
requirement as that is central to the charter of the project. Where any
auxiliary or emerging specifications are adopted by a component, whether
they are AMQP related or not, they should be compliant with that.
However, having a general policy where all Qpid components are required
to implement whatever 'emerging standards' come out of the OASIS AMQP
TCs is not something I am comfortable with.
The Qpid community as a whole needs to have a say in how future features
will work through an open, collaborative process (open to _anyone_, even
those primarily involved with other AMQP related projects or products).
Personally I think this would be better for AMQP as well. Allowing and
encouraging the emergence of grass-roots driven, de-facto 'standards'
developed in and between open, collaborative and transparent communities
and backed up by proven interoperable implementations, which can then
form the basis for official de-jure standardisation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
