qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Qpid Dispatch Router component
Date Thu, 10 Oct 2013 15:20:53 GMT
On 10 October 2013 15:35, Ted Ross <tross@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

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

-- Rob

> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<users-unsubscribe@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message