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. > agreed. > 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 (nope) 2. The unit tests must go with the code. I totally agree with everything you said. -Andy > d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
