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 Fri, 11 Oct 2013 10:42:51 GMT
On 10 October 2013 20:07, Ted Ross <tross@redhat.com> wrote:

> 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:

> 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.
To me that's *really* not the root of the issue at all.  The issue to me is
that I don't know what Dispatch is, how it differs in scope and vision from
a broker or other component, and how it fits into the Qpid story.  In
practice I probably do know because of off-list conversations, but I
couldn't get that information from the mails or documentation here.  I
think if we were to include the definition/description that Gordon gave
then we would have a really good scope statement on what it was about.

> 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.

Again this is really not what I'm saying.  As Fraser's mail indicates there
is currently no clarity in how the various Qpid components fit together.
What I want is for us to improve that by having a clear and *shared*
understanding of what all the components are.

> 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.
So, to reiterate I am in no way suggesting that Dispatch shouldn't be a
component in Qpid... I actually think it sounds like a really good idea and
something we should be doing.  However I think we should be aiming at
better explaining to ourselves and others what the goals behind our
components are.

i do think we were remiss in not setting up a proper scope statement for
the JMS client.  I'd actually suggest that we come up with one now and put
it to a vote to ensure that we have broad agreement on the proposed
component and to discover now if there are any misconceptions/disagreements
about the form that work should take.  I'll see if Robbie and I can come up
with something on that one (though obviously others are welcome to do the
work there instead :-) ).


> -Ted
> ------------------------------**------------------------------**---------
> 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