james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard O. Hammer" <ROHam...@EarthLink.net>
Subject Re: new InputStream class for mail data
Date Tue, 15 Jul 2003 06:35:24 GMT
I have described how I believe the recognition of "a period alone in a 
line" differs from the recognition of "CRLF.CRLF" in a few places, 
including this list:
<http://marc.theaimsgroup.com/?l=james-dev&m=105527214016488&w=2>
<http://www.imc.org/ietf-smtp/mail-archive/msg00710.html>

And I have described the different behavior which results from 
recognizing one or the other as the "end of data indicator" in the 
Javadoc at the head of the file SMTPDataInputStream.java which I 
submitted to this list in email on July 2.

I think I have said it clearly in those places, and I doubt that I do 
any good by saying it again now.


Noel J. Bergman wrote:
> Now, as for the code, itself.
> 
> As I said to Serge, I hadn't had time to test your code.  Also, I'm not
> quite sure what goal you are trying to achieve with the change.  Would you
> please elaborate?

I am responding in large part to my desire to understand my own code 
and to believe in it.  As I told before I am developing an email 
server which draws from James but which will differ in a number of 
respects.  I appreciate the lessons I learn from James and would like 
if possible to give back in some way.

In developing SMTPDataInputStream I was imagining that it might find 
use in both James and in my project.  I was trying mainly to write for 
my own project, taking the best of what I could learn from James while 
adding what I consider to be my own improvements.   But I thought that 
it might also be acceptable to the James project, so I shaped it to 
fit into James with as few changes as possible.

I see that this submission makes work for you if you undertake to 
implement and test it.  And it is in a part of James which, so far as 
I know, already seems to be working fine.  As such it may be best for 
you to set it aside and consider it no further, until such time as 
your priorities might bring you back to this area to do some refactoring.

> You wrote that "The code we are using now employs buffer after buffer, and I
> suspect that this redundant buffering may be unnecessary", but the only
> buffers that I am finding present in the SMTP handler at the moment (I could
> have missed something) are the BufferedInputStream assigned to "in", and the
> line buffer in CRLFTerminatedReader.

Thank you, I stand corrected in large part.  I guess I was assuming 
that one of CharTerminatedInputStream, BytesReadResetInputStream, 
SizeLimitedInputStream, or DotStuffingInputStream, employed a 
BufferedInputStream in addition to the BufferedInputStream already 
created in SMTPHandler.handleConnection(), and I see that is not the 
case.  As you point out, there is redundant buffering in that 
CRLFTerminatedReader extends BufferedReader (in code which I suggested 
last month); I now believe that redundant buffering should be removed. 
  I notice that DotStuffingInputStream keeps a two-byte buffer with 
every byte that passes through, and CharTerminatedInputStream keeps a 
little buffer whenever a CRLF passes through.

 > ...  The rest of the streams are
 > unbuffered, and just add behavior.  One is a FilteredInputStream 
subclass,
 > and the rest probably should be, including yours.

Thank you.  I had not considered extending extending 
FilteredInputStream.  From the Javadoc it does like that might be an 
improvement.  Why would you say it might be better?

Rich


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message