Hi Peter, On Wed, 4 Dec 2002 09:44, Peter M. Goldstein wrote: > It's actually almost exactly the same. I can say this with some > authority because I've done most of it. :) It's in the revision of > IMAP that I've got sitting on my box. I will, as I mentioned before, be > checking it in shortly after 2.1 is out the door. I, like all the other > committers working on 2.1, deferred further work on 3.0 until after 2.1 > is out the door.
This is unfortunate. I was unaware that anyone was working on the existing IMAP proposal. (Although looking back on an email of yours, you did mention that you were working on some patches). I never felt that proposals were included in the James2.1 code freeze, since they aren't a part of the release. As you are probably aware, I have written a new IMAP proposal (in proposals/imap2) which shares very little code with the existing proposal. I have a bunch of time on my hands at the moment, and I needed to immerse myself in a design/coding problem. IMAP was it - I hope I haven't caused waves by continuing to develop while other committers felt the need to hang fire. Earlier this year I did a significant amount of work on the first IMAP proposal. I added in the commands package, and got SingleThreadedConnectiionHandler down to 1/4 it's original size. But it was still complicated, convoluted, and hard to modifiy, debug etc. So when I came back to it this year, I decided it would be easier, better, and more fun to start from scratch. Being a bit of an XP fan, I spent a day jotting down some design ideas, grabbed the existing tests, and started trying to get them to pass. I've continually refactored as I've gone, and I'm pretty happy with the result. Where it made sense, I pulled classes from the original proposal, but not many, as it turned out. We now have an imap proposal which is IMHO cleaner, easier to develop, and more modular that the earlier proposal. It also doesn't carry the cut-and-paste-hell baggage of the original. The benefits of the new proposal over the old are: 1) Just as functional as the earlier, but easier to prove (since I have more tests) 2) Much closer to the spec on protocol issues like permissible arguments (handles both synchonised and non-synchronised literals whereever they are allowed). 3) More modular and extensible design, so new features and bugs are easier to implement/fix (you implement the features and fix the bugs, hopefully) 4) Doesn't include another MailRepository format, but simply defines the requirements it needs for storage. This should make it easier to arrive at a unified MailRepository in the upcoming James3 discussions. Let's get this sorted out straight away. The last thing we need is 2 competing IMAP proposals. Please commit the changes you've made - there's no point developing solo at home. And please have a look at what I've done. It's not perfect by any means, but I think it provides a much more solid foundation for an IMAP module for James. Then, let's get these James3 discussions started. I can't see any reason to wait. -- ciao, Daz -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
