james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Easy protocol logging
Date Wed, 04 Dec 2002 01:10:24 GMT


> This is unfortunate. I was unaware that anyone was working on the
> 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
> 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
> I
> have a bunch of time on my hands at the moment, and I needed to
> myself in a design/coding problem. IMAP was it - I hope I haven't
> 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
> was
> still complicated, convoluted, and hard to modifiy, debug etc. So when
> came
> back to it this year, I decided it would be easier, better, and more
> 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
> grabbed the existing tests, and started trying to get them to pass.
> continually refactored as I've gone, and I'm pretty happy with the
> Where it made sense, I pulled classes from the original proposal, but
> 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
> more
> tests)
> 2) Much closer to the spec on protocol issues like permissible
> (handles both synchonised and non-synchronised literals whereever they
> allowed).
> 3) More modular and extensible design, so new features and bugs are
> to
> implement/fix (you implement the features and fix the bugs, hopefully)
> 4) Doesn't include another MailRepository format, but simply defines
> 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
> developing solo at home. And please have a look at what I've done.
> not
> perfect by any means, but I think it provides a much more solid
> 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
> 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

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.


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message