Darrell, > 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.
Proposals aren't included in the code freeze. But in the interest of getting some momentum behind 2.1, the 2.1 committers agreed > 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. No waves. I've always contended that it's open season in proposals. Feel free to check in whatever you want in the proposals directory. Not going to bug me. :) > 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. I understand. I don't really agree, but I understand. > 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. Well, that's more debatable. See my comments below. > 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. 1) The tests, if correct should work for any IMAP server, right? That's the whole point - they're protocol tests. 2) It is better on the literals, although I don't particularly care for the form of solution as implemented. 3) This is arguable. Honestly, from my examination, it looks like the design has most of the modularity flaws and bad extensibility tradeoffs that were inherent in the other design. It's been my approach to evolve these out. Still in process. 4) True. And that's a good thing for API development, a bad thing for actually testing functionality. My approach was just to lock away the mailbox behind a simple interface. This is especially easy, as much of the implementation inside the mailbox is the previous implementation simply shouldn't be there. IMAP mailbox requirements are 95% defined by the UID rules and the requirements of the SEARCH command. > 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. Uh, as I said before, I've got a commitment to focus on 2.1. Your schedule doesn't change that one iota. That commitment precludes me devoting any serious time to 3.0 before 2.1 is out the door. Sorry. After 2.1 is out the door, and I've got time to neaten up the details on what I currently have, I'll commit it. Also, I don't really consider the "2 competing IMAP proposals" to be a manifest evil. Why is this a bad thing? I have actually taken a glance at what you've done. No offense, but I don't really see it as an improvement. Looks to me like a step backwards, honestly. It has most of the problems inherent in the old implementation. You're free to work on it, and I'll take a more detailed look at it once 2.1 is out the door, but my first impressions haven't been favorable. I suspect I'll want to stick with the older version, with the modifications I've completed. > Then, let's get these James3 discussions started. I can't see any reason > to > wait. Because we've got a release to get out the door, and a commitment to do so. It would be ethically irresponsible to abandon that commitment. James 3 discussions will wait until after 2.1 is out, as all of us agreed. You won't cause waves with me by checking in proposal code, but you will by attempting to derail developer commitment to James 2.1. James 2.1 comes first. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
