Ilja Booij wrote:
On Tue, 5 Oct 2004 20:38:27 -0000, Aaron Stone
<[EMAIL PROTECTED]> wrote:
I rather disagree that code to handle \r\n or \n-only should be any more
complex. Or, at the very least, that it should be intrinsic to a low level
enough handling routine that everywhere else the code doesn't need to care
what the line endings are.
True.
*Real* parsers would have no trouble with this. The problem is that our
current MIME handler is an over-extended hack that chokes on unexpected
input and just about every corner case it can find. That's not to bash on
Roel's code any more than is absolutely necessary, though :-P
It's been my assumption for a while that GMIME would be able to handle
both line endings. Ah, assumptions. We should probably make sure that it's
true!
I'm holding the same assumption. Paul, can you shed some light on
this? You seem to be the person with the most GMime experience.
I almost finished the new insertion code. I've refactored
read_whole_message_pipe, split_message and friends.
Anyway. GMime can handle any type of message you throw at it, as long as the message involved conforms to the
rfcs involved. It can handle CRLF -> LF and LF->CRLF with or without dot-escaping (smtp,lmtp) on the fly. It's
a basic part of the filter streams used extensively in gmime.
Currently I calculate rfcsize by parsing the message through a filter with has a LF->CRLF conversion attached
to it. The resulting stream-size is the rfcsize, the original message is left as-is.
I think I can finish the insertion code using gmime today.
Keep you posted.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
