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 Fri, 11 Oct 2013 12:31:59 GMT

On 10/11/2013 07:19 AM, Gordon Sim wrote:
> On 10/11/2013 11:52 AM, Rob Godfrey wrote:
>> On 11 October 2013 11:54, Gordon Sim <gsim@redhat.com> wrote:
>>> Second, the code in Dispatch Router is in theory designed around a 
>>> toolkit
>>> for building  AMQP 'containers' of different kinds, with the router 
>>> being
>>> one such example (another might be a proxy focused more on enforcing 
>>> ACLs
>>> at the edge). In theory this could be viewed as an API of sorts. 
>>> However I
>>> think at this point its better viewed as a sensible desire for some
>>> internal structure and separation of concerns. A publishable 'API' 
>>> is in my
>>> view some way off and would require a lot of work that would at this 
>>> point
>>> distract from the main goal, which is to define the behaviour of the 
>>> router
>>> and implement it.
>> This would be really cool... though I would hope/think this would 
>> lead to a
>> spin-off new component for the toolkit rather than being part of 
>> Dispatch
>> itself?
> That would make sense to me, though I think we should cross that 
> bridge if and when we ever come to it. (E.g. if a new component 
> emerges that wants to reuse some of the same codebase).
>>  As such (and for the reasons you also allude to) I would think
>> this would not be a goal of Dispatch itself, but rather some sort of 
>> stated
>> aim and guiding principle of the development.
> To me, the focus has to be on demonstrating the vision (and proving it 
> works and has value). The rest is just good programming practice 
> (modular design, with minimal coupling and maximum cohesion).
>>  Going off-topic a bit I
>> guess... but would we see such a framework as having multiple
>> implementations (in different languages) or only in C?
> Again, to me the language used is secondary to the goal of proving the 
> concept with real, deployable software. I do think that the 
> communication patterns on top of AMQP between routers should be very 
> clearly spelled out to allow clones or alternative implementations 
> following the same rules to be developed if anyone anywhere has the 
> desire to do so.

+1 on all of the above.

I'll add one more motivation/criteria for Dispatch.  Performance is a 
primary goal.  I've gone to some lengths to avoid bottlenecks in 
multi-threaded memory management and buffer/field management.  I believe 
that if Qpid has a flexible and scalable interconnect that does not 
introduce performance slowdowns, there will be many very interesting 
things that we can layer over it.


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

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

View raw message