qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: Qpid Dispatch Router component
Date Thu, 10 Oct 2013 18:07:11 GMT

On 10/10/2013 11:20 AM, Rob Godfrey wrote:
> 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 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.


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

View raw message