RE: James mailet+JCE

[Noel J. Bergman]

Removing jre/lib/ext from the classpath seems like an error.  That is
explicitly where shared libraries are supposed to go.  Separation of
classpath's shouldn't apply.

It would only make sense if the goal was to make SAR files self-contained,
except for Phoenix.

--- Noel

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 18:41
To: James Developers List
Subject: RE: James mailet+JCE


Frank,
the mailet classpath is controlled by Avalon Phoenix
http://jakarta.apache/org/avalon
If you're not familiar with avalon it provides james (I expect the Avaloon
guys will "correct" me robustly when i get this wrong!) with a runtime
platform "Phoenix", several services, and a lifecycle framework.

Phoenix ensures classpath separation amongst apps its hosting, which is
fine, but also (probably for good reasons) omits
jre/lib/ext from the classpath it provides its "blocks" with. if you're
using james 1.2a1-xx you could try putting the crypto provider in phoenix
own common lib dirs, which I think would be either james/lib or james/ext

I know one of these (can't remember which offhand) works for JDBC drivers,
check my JDBC related comments in the config file to find out what I used to
know ;-).

As far as telling Phoenix to include jre/lib/ext in the classpath it
provides, I'm not sure what to do, (if you are a *nix user I'd try linking
Phoenix /ext/ to jre/lib/ext, but thats not a portable answer).

You may get further by asking this same question on the avalon lists.
If you get a better answer anywhere let us know.

d.

> -Original Message-
> From: Frank Herrmann [mailto:[EMAIL PROTECTED]]
> Sent: 02 September 2002 22:59
> To: James developer list
> Subject: James mailet+JCE
>
>
> Hello!
>
> I'd like to use JCE (Java Cryptography Extension) inside a
> mailet. When I try
> to start James (run.sh) it throws the following exception:
>
> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
>
> AFAIK this only happens if the provider class is not in the classpath.
> (for me it is /usr/lib/java/jre/lib/ext/sunjce_provider.jar)
>
> When I compile (and run) the code snippet in a separate
> ("normal") java file
> it works like a charm.
>
> So the question is: How can I tell James where to find the
> sunjce_provider.jar
> file ?
>
> What I already tried: added classpath in /dist/bin/run.sh - no difference.
>
> $JAVA_HOME/bin/java -classpath
> /usr/lib/java/jre/lib/ext/sunjce_provider.jar
> $JVM_OPTS -jar $PHOENIX_HOME/bin/phoenix-loader.jar $*
>
> Greetings,
> Frank
>
> ---little code sample-
>  try {
>
> if (_DEBUG_CRYPTO) {
> // display providers we have available:
> secProviders = Security.getProviders();
> System.out.println(secProviders.length);
> for (int i = 0; i < secProviders.length; i++)
> {
> System.out.println(secProviders[i].getInfo());
> }
> }
>
>/* select provider SunJCE */
> secProvider = new com.sun.crypto.provider.SunJCE();
> Security.addProvider(secProvider);
>
>}
> catch (Exception e) {}
> 
>
> the full exception output
>
> James 2.0a3
> There was an uncaught exception:
> -
> --- Message ---
> Failed to initialize application james.
> --- Stack Trace ---
> org.apache.avalon.phoenix.interfaces.DeploymentException: Failed
> to initialize
> application james.
> at
> org.apache.avalon.phoenix.components.deployer.DefaultDeployer.depl
> oy(DefaultDeployer.java:183)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyFile(DefaultEmbeddor.java:467)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyFile(DefaultEmbeddor.java:461)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyFiles(DefaultEmbeddor.java:449)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyDefaultApplications(DefaultEmbeddor.java:439)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.exec
> ute(DefaultEmbeddor.java:182)
> at
> org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:115)
> at
> org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:101)
> at
> org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm
> pl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
> cessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Me

RE: James mailet+JCE

[Danny Angus]

Frank,
the mailet classpath is controlled by Avalon Phoenix
http://jakarta.apache/org/avalon
If you're not familiar with avalon it provides james (I expect the Avaloon
guys will "correct" me robustly when i get this wrong!) with a runtime
platform "Phoenix", several services, and a lifecycle framework.

Phoenix ensures classpath separation amongst apps its hosting, which is
fine, but also (probably for good reasons) omits
jre/lib/ext from the classpath it provides its "blocks" with. if you're
using james 1.2a1-xx you could try putting the crypto provider in phoenix
own common lib dirs, which I think would be either james/lib or james/ext

I know one of these (can't remember which offhand) works for JDBC drivers,
check my JDBC related comments in the config file to find out what I used to
know ;-).

As far as telling Phoenix to include jre/lib/ext in the classpath it
provides, I'm not sure what to do, (if you are a *nix user I'd try linking
Phoenix /ext/ to jre/lib/ext, but thats not a portable answer).

You may get further by asking this same question on the avalon lists.
If you get a better answer anywhere let us know.

d.

> -Original Message-
> From: Frank Herrmann [mailto:[EMAIL PROTECTED]]
> Sent: 02 September 2002 22:59
> To: James developer list
> Subject: James mailet+JCE
>
>
> Hello!
>
> I'd like to use JCE (Java Cryptography Extension) inside a
> mailet. When I try
> to start James (run.sh) it throws the following exception:
>
> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
>
> AFAIK this only happens if the provider class is not in the classpath.
> (for me it is /usr/lib/java/jre/lib/ext/sunjce_provider.jar)
>
> When I compile (and run) the code snippet in a separate
> ("normal") java file
> it works like a charm.
>
> So the question is: How can I tell James where to find the
> sunjce_provider.jar
> file ?
>
> What I already tried: added classpath in /dist/bin/run.sh - no difference.
>
> $JAVA_HOME/bin/java -classpath
> /usr/lib/java/jre/lib/ext/sunjce_provider.jar
> $JVM_OPTS -jar $PHOENIX_HOME/bin/phoenix-loader.jar $*
>
> Greetings,
> Frank
>
> ---little code sample-
>  try {
>
> if (_DEBUG_CRYPTO) {
> // display providers we have available:
> secProviders = Security.getProviders();
> System.out.println(secProviders.length);
> for (int i = 0; i < secProviders.length; i++)
> {
> System.out.println(secProviders[i].getInfo());
> }
> }
>
>/* select provider SunJCE */
> secProvider = new com.sun.crypto.provider.SunJCE();
> Security.addProvider(secProvider);
>
>}
> catch (Exception e) {}
> 
>
> the full exception output
>
> James 2.0a3
> There was an uncaught exception:
> -
> --- Message ---
> Failed to initialize application james.
> --- Stack Trace ---
> org.apache.avalon.phoenix.interfaces.DeploymentException: Failed
> to initialize
> application james.
> at
> org.apache.avalon.phoenix.components.deployer.DefaultDeployer.depl
> oy(DefaultDeployer.java:183)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyFile(DefaultEmbeddor.java:467)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyFile(DefaultEmbeddor.java:461)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyFiles(DefaultEmbeddor.java:449)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.depl
> oyDefaultApplications(DefaultEmbeddor.java:439)
> at
> org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.exec
> ute(DefaultEmbeddor.java:182)
> at
> org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:115)
> at
> org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:101)
> at
> org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm
> pl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
> cessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:88)
> at org.apache.avalon.phoenix.launcher.Main.main(Main.java:51)
> Caused by: org.apache.avalon.framework.CascadingException: Failed to
> initialize application james.
> at
> org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(
> DefaultKernel.java:134)
> at
> org.apache.avalon.phoenix.components.kernel.DefaultKernel.addApp

RE: [PATCH] IMAP - Append Command

[Andrew C. Oliver]

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:   
For additional commands, e-mail: 

James mailet+JCE

[Frank Herrmann]

Hello!

I'd like to use JCE (Java Cryptography Extension) inside a mailet. When I try 
to start James (run.sh) it throws the following exception: 

java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE

AFAIK this only happens if the provider class is not in the classpath.
(for me it is /usr/lib/java/jre/lib/ext/sunjce_provider.jar)

When I compile (and run) the code snippet in a separate ("normal") java file 
it works like a charm. 

So the question is: How can I tell James where to find the sunjce_provider.jar 
file ? 

What I already tried: added classpath in /dist/bin/run.sh - no difference.

$JAVA_HOME/bin/java -classpath /usr/lib/java/jre/lib/ext/sunjce_provider.jar 
$JVM_OPTS -jar $PHOENIX_HOME/bin/phoenix-loader.jar $*

Greetings,
Frank

---little code sample-
   try {

if (_DEBUG_CRYPTO) {
// display providers we have available:
secProviders = Security.getProviders();
System.out.println(secProviders.length);
for (int i = 0; i < secProviders.length; i++)
{
System.out.println(secProviders[i].getInfo());
}
}

 /* select provider SunJCE */
secProvider = new com.sun.crypto.provider.SunJCE();
Security.addProvider(secProvider);

   }
catch (Exception e) {}


the full exception output

James 2.0a3
There was an uncaught exception:
-
--- Message ---
Failed to initialize application james.
--- Stack Trace ---
org.apache.avalon.phoenix.interfaces.DeploymentException: Failed to initialize 
application james.
at 
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:183)
at 
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:467)
at 
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:461)
at 
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFiles(DefaultEmbeddor.java:449)
at 
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployDefaultApplications(DefaultEmbeddor.java:439)
at 
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute(DefaultEmbeddor.java:182)
at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:115)
at 
org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:101)
at org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:88)
at org.apache.avalon.phoenix.launcher.Main.main(Main.java:51)
Caused by: org.apache.avalon.framework.CascadingException: Failed to 
initialize application james.
at 
org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(DefaultKernel.java:134)
at 
org.apache.avalon.phoenix.components.kernel.DefaultKernel.addApplication(DefaultKernel.java:169)
at 
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:166)
... 14 more
Caused by: org.apache.avalon.framework.CascadingException: Block named 
"spoolmanager" failed to pass through the Initialization stage. (Reason: 
java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE).
at 
org.apache.avalon.phoenix.components.application.LifecycleHelper.fail(LifecycleHelper.java:417)
at 
org.apache.avalon.phoenix.components.application.LifecycleHelper.startup(LifecycleHelper.java:220)
at 
org.apache.avalon.phoenix.components.application.DefaultApplication.runPhase(DefaultApplication.java:176)
at 
org.apache.avalon.phoenix.components.application.DefaultApplication.start(DefaultApplication.java:88)
at 
org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(DefaultKernel.java:122)
... 16 more
Caused by: java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:130)
at 
org.apache.james.transport.MailetLoader.getMailet(MailetLoader.java:57)
at 
org.apache.james.transport.JamesSpoolManager.initialize(JamesSpoolManager.java:151)
at 
org.apache.avalon.phoenix.components.application.LifecycleHelper.startup(LifecycleHelper.java:199)
... 19 more
---

RE: [PATCH] fields in XOVER containing newline or tab disturb client

[Danny Angus]

Harmeet,
Are you going to commit this?
d.

> -Original Message-
> From: Christian Buchegger
> [mailto:[EMAIL PROTECTED]]
> Sent: 02 September 2002 19:53
> To: James Developers List
> Subject: Re: [PATCH] fields in XOVER containing newline or tab disturb
> client
>
>
>
> Using -Dapache.nntp.debug=true was my first aproach. But what I
> got was just
> an output like
> S: -1
> :( this is because in the implementation of  PrintWriter in
> NNTPHandler.handleConnection() only has a debug hook
> in println(), but does not overwrite print(). So I decided to assemble the
> line using StringBuffer rather than
> overwrite print() and buffer the data just for debugging purposes.
>
> So using this solution will give full usable output
> whenever -Dapache.nntp.debug=true has to be used next.
> I also checked that there are no further occurences of PrintWriter.print()
> calls which could produce
> missing debug data.
>
> Christian
>
> >> I don't think prt.print(..) to StringBuffer makes a
> >> difference. PrintWriter will buffer till println is called and
> it seems a
> >> bit cleaner.
> >>
> >> To debug NNTP protocol, it is best to change runscript to have system
> >> property -Dapache.nntp.debug=true. Client and Server communication for
> >> nntp will show up in the log file with prefix 'C: ' and 'S: '. This
> >> should help identify protocol problems. Helped me a lot.
>
>
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] fields in XOVER containing newline or tab disturb client

[Christian Buchegger]

Using -Dapache.nntp.debug=true was my first aproach. But what I got was just
an output like
S: -1
:( this is because in the implementation of  PrintWriter in
NNTPHandler.handleConnection() only has a debug hook
in println(), but does not overwrite print(). So I decided to assemble the
line using StringBuffer rather than
overwrite print() and buffer the data just for debugging purposes.

So using this solution will give full usable output
whenever -Dapache.nntp.debug=true has to be used next.
I also checked that there are no further occurences of PrintWriter.print()
calls which could produce
missing debug data.

Christian

>> I don't think prt.print(..) to StringBuffer makes a
>> difference. PrintWriter will buffer till println is called and it seems a
>> bit cleaner.
>>
>> To debug NNTP protocol, it is best to change runscript to have system
>> property -Dapache.nntp.debug=true. Client and Server communication for
>> nntp will show up in the log file with prefix 'C: ' and 'S: '. This
>> should help identify protocol problems. Helped me a lot.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] IMAP - Append Command

[Danny Angus]

> 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:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Andrew C. Oliver]

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:   
For additional commands, e-mail: 

RE: [PATCH] IMAP - Append Command

[Danny Angus]

> 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:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Andrew C. Oliver]

> 
> Are there test cases that don't run now, or are you worried that moving 
> it to the src dir will cause test cases to fail? (If the latter, why?).
> 
> Charles


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)

-Andy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Andrew C. Oliver]

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:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Andrew C. Oliver]

Cool I'll have to check that out!  That should be nice for writing unit 
tests!

lution, 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:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Charles Benett]

Andrew C. Oliver wrote:
> 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,

The opinion of anyone who is making a constructive contribution to the 
topic matters.

> 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.

Are there test cases that don't run now, or are you worried that moving 
it to the src dir will cause test cases to fail? (If the latter, why?).

Charles




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Charles Benett]

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:   
For additional commands, e-mail: 

Re: [PATCH] IMAP - Append Command

[Charles Benett]

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:   
For additional commands, e-mail: 

RE: [PATCH] IMAP - Append Command

[Sascha Kulawik]

> 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:   
For additional commands, e-mail: