> 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. 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. 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. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
