On 11 October 2013 13:19, Gordon Sim <g...@redhat.com> 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). > > Yeah - that makes sense.
> > 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). > > +1 > > 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. > > > Agreed on all the above :) -- Rob > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
