On 10 October 2013 15:35, Ted Ross <tr...@redhat.com> wrote: > > On 10/10/2013 04: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. >> > > Rob, > > Here's where I'm going to have to disagree with you in principle. I > believe that Qpid should be primarily directed at innovating with AMQP and > helping to drive the AMQP standards where appropriate. If Qpid doesn't do > it, somebody else will. I should point out that almost everything we do > here is well ahead of the standards, including the JMS client. > > The thing I object to in your statement is the direction of flow from the > standard to the implementation. Standards bodies _do not innovate_. If > the emerging standards are such that a particular valuable innovation > cannot be done, the standard needs to change or be ignored. Qpid must not > allow itself to be put in the position of meekly sitting and waiting for > the tablets to come from on high before implementing. > > I'm not saying that there is a direction of standard -> implementation, but that if there is a standard we should be implementing it rather than rolling our own which conflicts or substantially overlaps. If we see a standard emerging at OASIS and do not believe it is correct then we should be working to fix it at that venue. If we do work which we think is generally applicable to other AMQP implementations then we should be considering whether we want to push it as a standard at OASiS or elsewhere.
I absolutely don't think that Qpid should be restricted in scope to simply implementing the standards, and I strongly believe that Qpid can be a place where we innovate and then work towards bringing behaviours to a standards body. However I also think that when we do so we should state up front what it is we are trying to achieve. I also don't think that qpid should become a mini-GitHub for any project that is tangentially related to AMQP to simply use as a code repository. So, in the case of Dispatch, it certainly seems to include innovative ideas which do not form part of any AMQP standard (proposed or current) but also seems to hint at overlaps with such (emerging) standards in addressing and in management. In addressing I think it's important that any requirements for addressing that you believe are important for Dispatch are discussed and considered in the OASIS AMQP work... in the Management space I would very much hope that the emerging Management spec for AMQP would prove to be a foundation on which functionality could be built and I would be concerned for a number of reasons if you felt that Dispatch couldn't/shouldn't be using them. > So here's my proposed statement regarding Dispatch: > > Qpid Dispatch is an implementation of an AMQP-compliant router. Dispatch > is pursuing a specific approach to routing and addressing that may differ > from other approaches. The implementation will conform to all relevant > emerging standards (Management, Addressing, and Security) to the extent > that it is practical. In the event that there are parts of the > specifications that are not practical to implement, we shall provide > specifics to the standards committee in an effort to improve the > specifications. > > Around AMQP compliance that seems reasonable, but from the rest of that statement I'm not sure what "AMQP-compliant router" means... How does a router differ from a broker? Would you expect any special client APIs to form part of the router package or not? Would you expect any other implementations of Dispatch, or is it intended only to be in C? Is it intended to be embedded in other programs or always to act as a stand-alone executable? What I'm getting at with a scope statement is that we should be clear at the outset of projects what we are looking to achieve. We may deliberately leave thing very open, but then we should state that clearly too. In order to be able to have a clear story about how the components of Qpid fit together I think we should be clear before we set out on the journey of a component what we are looking to do (and what we are explicitly not looking to do). For previous components I don't think we've done that well enough (and for the upcoming JMS client I want to go back and rectify that omission). -- Rob -Ted > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
