On 10 October 2013 20:07, Ted Ross <tr...@redhat.com> wrote: > > 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: >>> >>> > [...]
> 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-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
