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

Cheers,
Rob


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

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