james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: [PATCH] IMAP - Append Command
Date Mon, 02 Sep 2002 14:18:31 GMT
Danny Angus wrote:
>>I think for the purpose of ensuring that we're compatible with actual
>>IMAP and not "MSIMAP" (probably a tm) having Mozilla or Eudora, etc
>>should be the guiding principal for judging this.
>>This is however far less important to me than the unit tests
>>issue.  I think they are
>>essential to a high quality IMAP implementation and I'm not apt to waste
>>my time creating low quality anything.
> No, fine, I completely agree.
> What I would say is that IMHO it isn't necessary to wait until we have a
> 100% sparkling product ready before we start to include it in James HEAD or
> in standard distro's, given suitable disclaimers.

Oh I totally agree with that.  My only issue is that SOME client other 
than outlook should be able to list the folders and get a message.

> In fact I believe that its inclusion would help to encourage the development
> effort, provide useful feedback and enlarge the team of active participants.
> We all know how to judge stds compliance, and I agree that unit testing is
> the way to go with regard to formalising this. But its also true, as we've
> already seen in James, that expected behaviour, and indeed "normal practice"
> isn't always completely aligned with standards' specifications, so to "gain
> market share" you have to support both the std and the expected non-std
> situation.

Of course!  And writing unit tests that mimic abberant behavior of say 
Outlook or Mozilla for instance is a good way to test these.

> I'm strongly of the opinion that these two different drivers, standards
> compliance and operation in real-life situations will drive development
> forward in unison, with no question about reduced quality. The standards
> based approach is being tackled already, the real-life drivers will appear
> once we start making access to IMAP easier for end-users.

> My main point being that I don't believe we have to claim the product is
> complete, just that it will provide some basic semblance of operation for us
> to start to make it available, I don't see why we shouldn't aim for a "high
> quality IMAP implementation" yet still release work in progress early and
> often, and get feedback from potential users.
agreed.  My issues:

1. Some client other than outlook (preferrably one that runs on some 
*nix) should be able to list the folders (that works) and get some mail 
2. The unit tests must go with the code.

I totally agree with everything you said.


> d.

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