|
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 <[EMAIL PROTECTED]> 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 |
_______________________________________________ Classpath-inetlib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-inetlib
