Hi guys, > -----Original Message----- > From: Rob Godfrey [mailto:rob.j.godf...@gmail.com] > Sent: Thursday, October 10, 2013 11:21 AM > To: users@qpid.apache.org > Subject: Re: Qpid Dispatch Router component > > 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.
The above is, as I see it, the crux of the matter. I agree with Rob on this item. Addressing and management are evolving standards in OASIS and they should not be ignored. The argument for evolving "de facto" standards is not really pertinent here (in the context of addressing and management). De facto standards emerge when some product/idea is developed and turned loose and people take off and run with it. In this case, work is ongoing at OASIS and other products are (I assume) implementing them. Ignoring that will only invite difficulties down the road, especially if Dispatch ends up only able to talk to itself. And I REALLY, REALLY want Dispatch to take off - I have big ideas for its use already. As far as the idea of a AMQP router, now that's an opportunity for de facto standard(s). As long as it interoperates with any other AMQP 1.0 endpoint that uses AMQP standard addressing and it responds correctly to AMQP standard management. Picture yourself as in Cisco's shoes 25-30 years ago. Take it from that approach and you'll be golden. > 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. Absolutely. -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
