I have not had much time to work on this project lately, as I'm sure you've noticed (yes, I did pick up the subtle hints from Andy ;)).
However, summer is getting to an end here, and so is the fishing season :(. I will be able to spend more time on the project from the end of next week.
As far as stuff assigned to me goes, I am prepared to commit to a completion date of mid April on the Hibernate mailbox implementation and JAAS authentication.
For the store:
- AOP transactions
me? accused of subtlety? Excellent Dawie. No expectations man. Just planning
Compression and AOP transactions sounds good. Subtly under AOP transactions ought to be "rip out all stateless session beans". Still, you'll need to make it work for 1.4 and 1.5 so at least you have a challenge. Hopefully Kabir watches, he knows a couple things about AOP.
Indexing is probably out of scope for M4. I would like to hear lots about thoughts you have to this effect. However, IMAP will force us to think in that direction so I want to wait until we get some basic IMAP which will likely start killing some of our assumptions on security/store/structure. Pieces of the house will fall, careful of the bricks.
Mike, I would like to get you branched out in a couple of places. Prevent too much specialization.
Rather than using annotations directly to mark the transactions, an option to avoid 1.4 and 5.0 annotation style issues would be to apply the tx attributes via metadata.
Or you could look at using annotation introductions
The main AOP docs page is here
- Refactor the Message class hierachy. I would like to see if we can have a single represenation of a Mail for the whole system. 'Mail sources', e.g. Protocols, Mailboxes, other services (Fetchmail) could use a standard set of factory methods to create mail objects (one that takes a set of properties, another an input stream etc). At the very least I would like to push more functionality up the hierachy and see it reused across the protocols and mailboxes.
- Revisit NIO. In order effectively use NIO we would need to modify protocol to work in a manner that does not require a 1:1 correlation of threads to connections. My suggestion would be to not change the existing Protocol but introduce a new protocol class (NIOProtocol?) that would work in a non-blocking manner and use channel/buffers rather than streams (or possibly our own I/O abstraction). Then as we introduce new protocols (IMAP, MAPI...) we use the NIOProtocol as the base class. Also allow the services using the old protocol to run side by side with newer services and migrate them as time dictates. The one issue is supporting JDK 1.4 and SSL together. We could use a adaptor to allow newer protocols to work with the existing Server as it is possible to create a Channel from an InputStream. It won't be as scalable as the NIO implemenation but wouldn't significantly worse than the existing system (you end up with an extra layer of buffering between the channel and the stream). It would just give users/customers the option of making the system more scalable if their infrastructure allows.
Humm, I defintely do not want to do NIO for M4 and do not want to require JDK5 for SSL until JDK5 is more prevelent and JDK1.4 more on the back burner. I prefer refactoring the entire framework not to require a 1:1 correllation between threads to connections as the main stream protocol. However, I'm thinking you're right that might be best done in parallel (if you look I have an NIOServer in CVS already which started that) just to avoid a labor constraint vs a period with a non-working server or some kind of massive long running CVS transaction... The new non 1:1 correlation stuff ought to work for both non-blocking and blocking IO and eventually the mainstream stuff should be deprecated for it. I suggest looking at the work being done on Tomcat 5.5's HTTP11 and new AJP connector stuff for a guide on how to pull that off. I think they manage to do that W/O NIO!!! Thoughts?
Andy, you are right about the new AJP connector stuff that Mladen did being very fast (actually faster than NIO). However, it is done using native code, so would have to consider if that would be acceptable for jboss mail. If it is, then don't think you'll find any faster way to do it (and the API is clean and simple), but will make install more complicated.
Ohhh I thought it didn't use native code for the HTTP connector side which was about as fast as apache. Now I kinda don't believe all the voodoo (keep alive with 1 second between is probably not the norm ;0).. I like the idea of NIO but I'm not ready to leave JDK 1.4 behind. The idea is to have a 1.0 release in the nearer term which means JDK 1.4 is still a factor (there are a lot of platforms with no JDK5 release yet). After the 1.0 then we refactor to all NIO because by 2.0 we don't care about 1.4 anymore.
Even with release 2.0 I would like to maintain jdk 1.4 compatibility. I think we could do it through some kind of adapter layer. Wouldn't be as good as the NIO stuff, but would provide a fall back for users that need it. I would probably only drop 1.4 support completely if it turned out to be a real pain to maintain.
I will put this on the back burner and focus on 1.0 features for the time being.