On 10/10/2013 11:20 AM, Rob Godfrey wrote:
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 here's the root of the issue. The question is whether or not
Dispatch is too tangential in its relation to AMQP to be considered
appropriate to be hosted in Apache Qpid.
You stated later in your email that you don't know what an
AMQP-compliant router is. Well, nobody really does because nothing like
it has ever existed. The very idea was not even conceivable before
there was an AMQP 1.0. But now we have AMQP and a door has been opened
to create really interesting solutions to difficult problems in
large-scale distributed computing. Dispatch is an early attempt to
implement such a solution. If we decide that by "tangential" we mean
"beyond the scope of traditional broker-based messaging", then Dispatch
is clearly tangential and I will go and find another community to host it.
The only way to know if a project will have long-term value is to let it
run for awhile. It's a form of incubation. We need a way, as you
suggest, of deciding what to incubate. We then need a way to decide
when a sub-project has failed and should be abandoned. Given that we
have no such guidelines in place, I intend to go forward with the same
process we used for the JMS project. If there arises a consensus in the
community that Dispatch does not, or might not belong in Qpid, I will
not go forward.
In the mean time, I will try to fill in some of the gaps in information
that you've identified.
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
