Is multifile fixed or broken in 2.2?

[Stuart D. Gathman]

On Sun, 06 Oct 2002 03:45:16 -0400, Martin v. Loewis wrote:

> "Stuart D. Gathman" <stuart at bmsi.com> writes:
> 
>> In the small test program below, python-2.1 reads one more newline than
>> python-2.2 on the multipart section.  Which one is right?
> 
> That's difficult to say. Python 2.2.2 will restore the 2.1 behaviour,
> for compatibility. This may not be strictly in compliance with all
> applicable RFCs, but the 2.2 multifile fixes were causing other
> problems.
> 
> So it has been decided that multifile stays as it is; users wishing to
> process MIME properly should use the email package.

The email package, like mimelib, seems to suck the entire message into
memory.  (Please tell me I'm wrong.) I process a lot of messages, which
can be 30 Megs or more in size.  The milter process cannot keep these in
memory to work on them, or it thrashes.  There is no problem having
multiple threads working on spool file copies of the messages.

I need to be able to have the Message object refer to a file location.
This is why I had to write my own 'mime' package instead of using mimelib.
 While most features are the same, 'mime' has file like objects for raw
leaf message parts, whereas email/mimelib have strings.

What is the rationale for continuing to use strings rather than file-like
objects for raw message parts?  I hate reinventing the wheel, but I can't
keep the messages in memory.  I can't just extend the standard API as long
as it uses only string as the type of raw message parts.

Could I work around this by creating a string-like object that reads a
seekable file like object?

-- 
Stuart D. Gathman <stuart at bmsi.com>
Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - Mozart background
song for the Microsoft "Where do you want to go from here?" commercial.