>>>>> "AM" == Andrew McNamara <[EMAIL PROTECTED]> writes:
>> Ug. It's probably inevitable, but I really don't want Mailman
>> to become a hypergeneralized MIME slicer-n-dicer.
AM> Yes - I think it's sort of inevitable. If you structure your
AM> MIME parser correctly, it may be relatively painless.
I think mimelib is pretty good, certainly better than anything else
I've seen for Python. I've got some nits about its interface, which
I'll need to clean up for any 1.0 release (or for inclusion in Python,
and I know Guido has some nits).
AM> BTW, you should look at the perl MIME module (as used by
AM> Majordomo 2) - I understand that it's one of the best MIME
AM> interfaces around (although reading other people's perl is
AM> futile, it's interface doco might suggest some ideas for your
AM> code).
Do you have a reference? I gave up Perl almost 7 years ago, so I
know I couldn't read it, but if the interface spec is online, I'd love
to take a look.
AM> It will also be a good test for your Python MIME code - if
AM> it's going to cope with the random crap that people mail
AM> around, it shouldn't have much trouble producing this.
It's actually fairly easy with mimelib.
AM> Personally, I find MIME problematic - the basic idea was okay,
AM> but when people start nesting objects several levels deep the
AM> utility starts to disappear. Also, it assumes that SMTP is a
AM> file transport protocol, which it isn't (if it was, it would
AM> support restarting failed transfers). I also turn it off in my
AM> MUA (exmh) as it slows it down considerably.
I agree. Also, I've find that generating MIME correctly really
requires holding the entire message hierarchy in memory and making
several passes over the generated text before you can really start
outputing correctly. That sucks too.
Thanks for the feedback.
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
