<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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
