james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <darr...@apache.org>
Subject Re: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Date Fri, 06 Dec 2002 08:08:07 GMT
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:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message