Let's try to narrow this list down a bit for a target M5 timescale ? As we've chatted about, I agree we should timebox our releases. But I think the Doctor might struggle with that lot before end March :-)
Bfn, Marnie On Thu, Jan 15, 2009 at 2:40 PM, Aidan Skinner <ai...@apache.org> wrote: > 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 >
