Re: [PATCH] IMAP - Append Command
No I'm afraid that the code will be merged without the test cases. Anyhow all I said is that the test cases should move with the code. Yes there are testcases that do not run now. That is not an issue. For this type of development I personally prefer test-first design. (meaning capture a subset of the spec or some mail client behavior and record the expected responsesTHEN make it actually so) It isn't easy as it seems. Within the FETCH Command you have a whole different possiblities for getting the Body, as I've seen Mozilla does not especially declares, that he wants to get the body of the mail - thats the point why it currently don't views the message content. I think, today or tomorrow I'll will be ready with that. The other point is the Append command - in some cases not all of the header-fields are correct submitted. I like testing with something living, like a real mailclient. Thats why I haven't checked the test-cases yet. IMHO Stephan wanted to check all of the test-cases. Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Sascha Kulawik wrote: No I'm afraid that the code will be merged without the test cases. Anyhow all I said is that the test cases should move with the code. Yes there are testcases that do not run now. That is not an issue. For this type of development I personally prefer test-first design. (meaning capture a subset of the spec or some mail client behavior and record the expected responsesTHEN make it actually so) It isn't easy as it seems. Within the FETCH Command you have a whole \ No its really easy to make test cases for this. Check it out. -Andy different possiblities for getting the Body, as I've seen Mozilla does not especially declares, that he wants to get the body of the mail - thats the point why it currently don't views the message content. I think, today or tomorrow I'll will be ready with that. The other point is the Append command - in some cases not all of the header-fields are correct submitted. I like testing with something living, like a real mailclient. Thats why I haven't checked the test-cases yet. IMHO Stephan wanted to check all of the test-cases. Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
On Sun, 01 Sep 2002 11:51:37 -0400, Sascha Kulawik wrote: No probb :) I'm developing under Windows, so it was the easiest way to test the IMAP functionality. I've also a Linux Box here and will test the features also under Evolution, Kmail and Mozilla. You can also use Mozilla on Windows. Andrew, correct, my standard-Browser under Windows is already Mozilla, but I haven't installed the complete suite because of some problems using Outlook and Mozilla side-by-side. My first step was to check the functionality with ONE Mailclient then with 10 parallel. Now it is functional under Outlook and Outlook Express, so I can test with other Mailclients. After testing with KMail and Evolution I want to check all commands, if they are completely RFC2060 compilance implemented, but the first steps for me was to bugfix the code and lean how it is implemented. So beware, that I will do that this week. The problem is, that the FETCH, LIST and SEARCH Commands are very complex, and so it was the first step to get this stuff working. I'm thinking of a complete redesign of these commands, but right now a patch would be all what we need :) Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Sascha Kulawik wrote: If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. I have no need for email viruses. No chance I'm installing that piece of junk on one of my machines. No probb :) I'm developing under Windows, so it was the easiest way to test the IMAP functionality. I've also a Linux Box here and will test the features also under Evolution, Kmail and Mozilla. You might want to test with a Pine client. As I recall, you can set Pine to protocol debug and easily see what it is trying to do (or what responses from James it doesn't like). Charles -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
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. 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. +1 I agree with Danny. Charles -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
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]
RE: [PATCH] IMAP - Append Command
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. Oh, fine, we're just splittin' hairs then :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: 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. Oh, fine, we're just splittin' hairs then :-) I think so yes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
No I'm afraid that the code will be merged without the test cases. Anyhow all I said is that the test cases should move with the code. Oh, yeah they'll move with the code. IMAP was in the HEAD with its tests (I think) until quite recently, but we backed it out owing to lack of progress. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
On Mon, 02 Sep 2002 10:29:48 -0400, Danny Angus wrote: No I'm afraid that the code will be merged without the test cases. Anyhow all I said is that the test cases should move with the code. Oh, yeah they'll move with the code. IMAP was in the HEAD with its tests (I think) until quite recently, but we backed it out owing to lack of progress. d. Then I'm happy with that :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
I think I'm learning this. I gave up for the night after a few hours of trying to solve phoenix barfing and telling me what to do. I'm probably going to try the reverse. Copy build.xml over build-imap.xml versus trying to solve all build-imap.xml's issues and try and figure out what needs to go in it to make it build the imap stuff. This should be fairly simple, I don't think there is anything IMAP specific about the IMAP build, except that it is a fork of an older build.xml file. Here is what I have to do to get it to work: 1. check out the 2.03a branch 2. muck with those (inc the normal) build files until they can actually find ant on unix as advertised (the docs and stuff LIE LIKE DOGS, I just don't know what of my tinkering actually worked) Some of the docs are way out-of-date since the phoenix changes came in. At some point if I get stumped would you be willing to take some patches to the build, and see if you understand the phoenix issues its griping about? Yes. if you have easy to reproduce breakages I'd be happy to give you pointers, but no too much time to fix stuff myself. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Sascha Kulawik wrote: Eeenteresting. I'll take a look but I tried to build it 2 days ago and I had a holy heck of a time getting it to build. the build-imap.xml file seems to be expecting a drastically different directory structure and locations than the HEAD. it pre-dates big changes that were made to upgrade phoenix. The changes are done - and it was comitted on Tuesday. Ehhh? I check out the head and it doesn't work. I don't yet have time to sort this out but my plan is this: 1. Get build-imap.xml and build-test.xml to work out of the box when checking out the head -- submit this +1 The build-test.xml will be done by Stefan Schiessling, I'm not a ANT-Wizard, so I havent changed the build-file for the IMAP trunk. But is this needed, if IMAP will be in the Main trunk ? It is needed to prove IMAP should be in the main trunk. 2. look into what it would take to move it into the head and submit that ensuring its fully turn-offable Basically its not hard, its a conifg thing, but we *must* be able to deal with whatever the conflict in james.java is. I still don't think we'll be miving it back into the HEAD until its been shown to build *and* work, at least to some degree. (I can't get it to work) If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. I have no need for email viruses. No chance I'm installing that piece of junk on one of my machines. -Andy Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. Sascha, If I compile James with IMAP will James be exactly the same in operation if I don't enable IMAP, than James without IMAP compiled in? If the answer is yes, and I can make it work with at least one IMAP client then I'd be prepared to vote in favour of moving it back into the HEAD. Not that my opinon should matter much, but I'm -1 unless the test cases go with it and can run (I'll help as much as my abillities allow). I consider them absolutely crucial to having a solid standards-compliant implementation. Currently it does not work with either IMAP client I have access to Mozilla or Ximian. -Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: I think I'm learning this. I gave up for the night after a few hours of trying to solve phoenix barfing and telling me what to do. I'm probably going to try the reverse. Copy build.xml over build-imap.xml versus trying to solve all build-imap.xml's issues and try and figure out what needs to go in it to make it build the imap stuff. This should be fairly simple, I don't think there is anything IMAP specific about the IMAP build, except that it is a fork of an older build.xml file. There are a few things in it specific to the proposals dir, etc. Here is what I have to do to get it to work: 1. check out the 2.03a branch 2. muck with those (inc the normal) build files until they can actually find ant on unix as advertised (the docs and stuff LIE LIKE DOGS, I just don't know what of my tinkering actually worked) Some of the docs are way out-of-date since the phoenix changes came in. At some point if I get stumped would you be willing to take some patches to the build, and see if you understand the phoenix issues its griping about? Yes. if you have easy to reproduce breakages I'd be happy to give you pointers, but no too much time to fix stuff myself. Great. Thanks. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. Sascha, If I compile James with IMAP will James be exactly the same in operation if I don't enable IMAP, than James without IMAP compiled in? If the answer is yes, and I can make it work with at least one IMAP client then I'd be prepared to vote in favour of moving it back into the HEAD. The answer is yes. The configuration variable will be readed inside james.java and therefor a store will be choosed, so you can compile everything with IMAP and don't use it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
Not that my opinon should matter much, but I'm -1 unless the test cases go with it and can run (I'll help as much as my abillities allow). I consider them absolutely crucial to having a solid standards-compliant implementation. Currently it does not work with either IMAP client I have access to Mozilla or Ximian. Should I send you my working-dir of James ? :) I can't explain me, why you can't use it. Do you can explain, where your problem is ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
Not that my opinon should matter much, but I'm -1 unless the test cases go with it and can run (I'll help as much as my abillities allow). I consider them absolutely crucial to having a solid standards-compliant implementation. I would be +1 to have experimental IMAP in the head if.. 1/ it was being actively developed 2/ it provided some basic functionality, not necessarily compliance or 100% of anything. 3/ was off by default in release builds. I think 1 3 are so, so my remaining objection is only 2, which Sacha believes is acchieved Currently it does not work with either IMAP client I have access to Mozilla or Ximian. No, me either. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
On Sun, 01 Sep 2002 11:51:37 -0400, Sascha Kulawik wrote: If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. I have no need for email viruses. No chance I'm installing that piece of junk on one of my machines. No probb :) I'm developing under Windows, so it was the easiest way to test the IMAP functionality. I've also a Linux Box here and will test the features also under Evolution, Kmail and Mozilla. You can also use Mozilla on Windows. -Andy Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
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]
Re: [PATCH] IMAP - Append Command
I think you're right and we're ready, but we need to get IMAP up to the same dependency tree as the head. It still won't build with it. -Andy Sascha Kulawik wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver Sent: Wednesday, August 28, 2002 2:40 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] IMAP - Append Command Personally, I think we should look for a way to componentize JAMES far enough to where building in IMAP is as simple as flicking a switch so that there is no need for a divergent versions of things. It IS currently possible to switch imap off or on - compiled in the main trunk. So it also would be possible to let the IMAP-Trunk reside inside the Main-Trunk. Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
-Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver Sent: Saturday, August 31, 2002 1:38 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] IMAP - Append Command I think you're right and we're ready, but we need to get IMAP up to the same dependency tree as the head. It still won't build with it. -Andy Thanks Andy, I've done the changes for the same dependencies, thats the changes Ive committed on Tuesday. So it would be possible to build IMAP with this changes. It's still needed, to change the Avalon-Configuration, but this won't affect if you will not use IMAP. Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Cool. Then it sounds pretty sensible to move it to the main trunk at this point. Sascha Kulawik wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver Sent: Wednesday, August 28, 2002 2:40 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] IMAP - Append Command Personally, I think we should look for a way to componentize JAMES far enough to where building in IMAP is as simple as flicking a switch so that there is no need for a divergent versions of things. It IS currently possible to switch imap off or on - compiled in the main trunk. So it also would be possible to let the IMAP-Trunk reside inside the Main-Trunk. Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Personally, I think we should look for a way to componentize JAMES far enough to where building in IMAP is as simple as flicking a switch so that there is no need for a divergent versions of things. -Andy Danny Angus wrote: Sascha, I'm happy to work with you to get these changes in, then to assess IMAP and propose a vote if it appears to be half way stable, but 1/ please could you help me by making your patches conform to the guidelines http://jakarta.apache.org/james/contribute.html diff -u from the /proposals/imap dir, and zip new files from there too. Then I don't have to work out paths, and go looking for files to patch. and 2/ Perhaps if I add a task to the main build file that will build James with IMAP that would be a reasonable interim before we put it back into the HEAD. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] IMAP - Append Command
There was an error by adding a File from a local directory. (Resolved). In SimpleMessageAttribute there will be setted the actual Date if there was no date submitted within the APPEND Command. Regards, Sascha Index: AppendCommand.java === RCS file: /home/cvspublic/jakarta-james/proposals/imap/java/org/apache/james/imapserve r/commands/AppendCommand.java,v retrieving revision 1.2 diff -r1.2 AppendCommand.java 128c128 long messagelen = Long.parseLong(ms.substring(1,ms.length()-2)); --- long messagelen = Long.parseLong(ms.substring(1,ms.length()-1)); 138a139 140c141,142 messageleft = messageleft - buffer; --- System.out.println(APPEND WRITTEN: +buffer+ BYTEOUTSIZE:+byteout.size()); messageleft = messagelen - byteout.size(); *CVS exited normally with code 1* attachment: winmail.dat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
Sascha, I'm happy to work with you to get these changes in, then to assess IMAP and propose a vote if it appears to be half way stable, but 1/ please could you help me by making your patches conform to the guidelines http://jakarta.apache.org/james/contribute.html diff -u from the /proposals/imap dir, and zip new files from there too. Then I don't have to work out paths, and go looking for files to patch. and 2/ Perhaps if I add a task to the main build file that will build James with IMAP that would be a reasonable interim before we put it back into the HEAD. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
Sascha, I'm happy to work with you to get these changes in, then to assess IMAP and propose a vote if it appears to be half way stable, but 1/ please could you help me by making your patches conform to the guidelines http://jakarta.apache.org/james/contribute.htm l diff -u from the /proposals/imap dir, and zip new files from there too. Then I don't have to work out paths, and go looking for files to patch. Sorry, no Problem. I thought, you would put it into the imapserver dir without checking all of the diffs, because of the proposal-state. and 2/ Perhaps if I add a task to the main build file that will build James with IMAP that would be a reasonable interim before we put it back into the HEAD. Yes, that would be really GREAT ! :) As I said, I'm not an expert in ANT, so this would be a good job. Also it's needed to include the config-files I've used (with the expected blocks inside) and the imap-compilant james.java :) Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
