qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <aidan.skin...@gmail.com>
Subject Re: Planning M5/ or whatever we call it
Date Fri, 16 Jan 2009 14:26:39 GMT
On 1/15/09, Robert Greig <robert.j.greig@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/%3Ca4265f2a0808220232v6fc79992ja174c9db2ad46167@mail.gmail.com%3E

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

Mime
View raw message