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 <g...@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.
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
