On 1/15/09, Robert Greig <robert.j.gr...@gmail.com> wrote: > I buy the argument that a full java multi-protocol bonanza is not > achievable in M5 timeline. And I also agree that one of the key things > users want is a stable product even in unforseen production > circumstances, so flow to disk would seem to be an important feature > to add for M5. > > So if we accept that M5 will be a stability release, do we want to > risk destabilising other areas by performing signfiicant refactoring?
No, which is why I suggested the bits of refactoring that are at the "good hygiene and cleanliness" end of the spectrum rather than the "rip it out with a chainsaw, throw it up in the air and put it back together with a blowtorch" end. The I/O stuff is mostly about decoupling the protocol handler from MINA, particularly the reliance on MINA byte buffers. The seperation of the store into a transaction log and a disk store is similary more about simplyfying (sp!) existing code, in this case seperating message body storage and retrieval from metadata. > And I really think we should bin this silly Mx release numbering > convention:-) That's an entirely different barrell of fish kettles full of worms. My opinon hasn't changed since we discussed this in August: http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200808.mbox/%3ca4265f2a0808220232v6fc79992ja174c9db2ad46...@mail.gmail.com%3e - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org
