Hi Tim, comments inside...
2010/5/29 Tim-Christian Mundt <[email protected]>: > Hi, > > for keeping a log of my GSOC project and gathering all related material > (including source code) I set up a Trac: http://maildir.tim-erwin.de/ > > There's not too much going on, yet, however, this will change soon. > > I did some research on the file transaction stuff and javamaildir. > > a) The commons-transaction project is dormant because they say file > transaction is impossible: >> +<p>We have decided to move the project to dormant as we are convinced that >> the main >> +advertised feature <em>transactional file access</em> can not be >> implemented reliably. >> +We are convinced that no such implementation can be possible on top of an >> ordinary file system. >> +Although there are other useful parts (as multi >> +level locking including deadlock detection) the transactional file >> +system is the main reason people use this library for. As it simply >> +can not be made fully transactional, it does not work as advertised. >> +</p> > > I don't want to introduce dead dependencies into James. An alternative > would be xadisk. However, this seems to be a one man, one commit show. I > don't really feel comfortable with it. Instead of using a > TransactionManager in the first place, I'd start with regular file > operations and later add some minimal transaction support or what ever > is needed to make James reliable. Any opinions? Yeah I think we should be ok without transactions here most of the times. Even in JCR implementation we don't use transactions. So implement something "easy" is a good idee.. > > b) Although I read a whole bunch of emails and comments the former > attempt to introduce maildir into James, I don't really get the whole > thing what "happened" back then. I feel kinda dumb, because I'm supposed > to implement a maildir library and don't know about the already existing > javamaildir library. Could anybody sum up in a few words why javamaildir > was not used? All I know is, that it didn't support all functions needed > for IMAP. > To make it short javamail suxx when used as "server" component. javamail needs to load the whole message into memory most of all times, so its not really a good fit for "high traffic / performance". The other problem is, javamail is to strict on malformated messages. Thats why we dedicited to not use any javamail based storage. The other problem with the maildir javamail lib was the lack of some methods (as you found out already). > Thanks in advance, > Tim > Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
