On 10 October 2013 11:49, Gordon Sim <g...@redhat.com> wrote: > 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. >
Saying that all Qpid components implement all emerging standards is clearly not what I am saying, because not all standards are appropriate for all components. However I think the point of Qpid (vs. any other messaging implementation at Apache or elsewhere) is to implement the AMQP specification. I'd generally question why work was being carried out in Qpid (as opposed to elsewhere) if the work is not based on existing or emerging AMQP standards. > > 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). > > i completely agree. > 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. > > Possibly, but I think that any such efforts at de-facto standardisation must first reach out to other AMQP implementers and ensure there is a broad agreement on direction. If the Qpid project can be a vehicle for doing this, then great - however currently that is not how Qpid is operating and I would be very concerned at us trying to claim any sort of work done within Qpid as a "de-facto" standard. Where there is qork going on in AMQP then we as the Qpid community should be ensuring that we feed back to that and raise questions/objections as necessary (whether we are part of the OASIS group or not - feedback from the public is possible). -- Rob ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
