Re: [Classpath-inetlib] Problems in gnu.inet.util.LineInputStream and gnu.inet.util.CRLFInputStream

[Robert Mitchell]

One way around the problems with mbox, etc. is to filter them to add the CR to the end of line sequence.

 

All that aside, I do not think it would be worth changing the architecture unless the current implementation is considered incompatible with the JavaMail specification.  I think this is an area where the specification is incomplete, although you might argue that the references to the Internet mail RFC's requires CRLF endings for javax.mail.internet implementations at a minimum.

 

Thanks,

Bob Mitchell.

>>> Chris Burdess <address@hidden> 4/5/2005 2:52 AM >>>

Robert Mitchell wrote:
> It sounds like it would work OK, and it would eliminate the single array
> copy my implementation has.  You would have to worry about the special
> case where your first CR is at the end of the buffer.  You would also
> have to implement something like what I wrote  or read one byte at a
> time for the case where mark is not supported.
> 
> By the way, after thinking about it some more, it seems to me that the
> only "safe" way to implement mark in CRLFInputStream is to double the
> parameter before passing it to the "in" InputStream.  For its current
> uses the current implementation is probably safe, but for mark/resets
> that enclose an arbitrary number of lines being read, it will not be
> safe.

OK, I'll have a go bearing this in mind.

> Personally, if re-architecting the inetlib/javamail design were
> possible, I would eliminate CRLFInputStream and incorporate the CR
> dropping into LineInputStream.  I might also do what I expect Sun's
> implementation does and where appropriate, require that the data use
> CRLF as the end of line character.

The problem is that some message sources will definitely not use CRLF as
a line delimiter, e.g. the mbox and Maildir stores. Note that these
stores are not supported by Sun's implementation either.
--
Chris Burdess