On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack <marnie.mccorm...@googlemail.com> wrote: > On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner <aidan.skin...@gmail.com>wrote: > >> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <g...@redhat.com> wrote: >> >> >> If the features on the page for M5 are more, shall we say, aspirational >> - >> >> let's use them as a roadmap for 2009. >> > >> > I'm certainly keen on understanding how our roadmap will take us to the >> > point where all Qpid components interoperate with each other. If it is >> not >> > feasible for the next release thats fine. >> >> I suspect the most achievable way to approach this is to refactor the >> broker and improve the test coverage for M5, then add extra protocols >> after that. >> >> What refactoring would you propose for M5 ?
The modularisation and decoupling described at http://qpid.apache.org/java-broker-modularisation.html I'd probably start with the event model, I/O layer and peristance interfaces. Flow to disk will be a lot easier to implement with a clear seperation between a transaction log and a retrieval store (which are really two separate things). The event model and I/O layer are the areas that will require the most modification for implementing additional protocols and are currently, IMVHO, the messiest. If this was done right it would also allow us to address the problem with unbounded buffers (QPID-1447 and friends). The session and model changes aren't as large, and don't have as much of an impact. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org
