On Thu, 5 Dec 2002 04:54, Sascha Kulawik wrote: > > I plan to do a bit more work on the IMAP proposal in the next > > few months. How > > much work, I can't be sure, and please feel free to help out, with > > contributions to code, constructive criticism, or flame mail ;). > > Hi Darrel, > > I've also done some stuff with the current IMAP code, and I'm also > interesed to contribute in the future. Currently it's not possible for > me, because of my daytime job - but I'm also interesed in UML Models, if > you had made some of that I could think about it :) > > Regards, > > Sascha
Hi Sascha, I did a bunch of work on the IMAP proposal earlier this year - mostly refactoring work to pull all of the command methods into separate command classes, and introducing the way that a command specifies it's arguments in the constructor. I was inactive on this list while you were contributing, but I've since had a look at the new APPEND functionality. In seeing how much work there was involved in getting the command going, I thought "there must be a better way". I started coding, got carried away, and ended up with a brand-new proposal. You can have a look at the new proposal at: http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/ My primary goal was to make it easier to add new functionality, and to fix problems. In fact, once I got the core running, it only took a couple of days to implement about 10 different commands. (I can't conclusively attribute this ease of development to better design, or a better test infrastructure - I reckon it's a bit of both). On the test side of things - it's now possible to execute the protocol tests without ever starting up Phoenix. This makes it *much* easier to run the tests, and *much* easier to debug them when they fail. I did almost all of my development using simple file-based protocol tests, and didn't connect an Email client until every command was implemented (at least partially). I was very pleased to find that it only took me a couple of hours to get KMail to connect, create & delete mailboxes, append mail, copy mail, and set flags. The only reason it didn't work straight off was stuff that wasn't fully implemented in my rush to test a real client. I'd love to hear your thoughts on the new proposal. I understand that you put some effort into the old one, and I don't want to undermine those efforts. But have a look, run the tests, and see what you reckon. There's a bunch of stuff still to do, but we can have fun doing it!! -- ciao, Daz PS: Yep, I'm hoping to get a few UML(esque) diagrams done at some stage. That would definitely assist people to grasp the design more easily. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
