[Mailman-Developers] [PATCH] mimelib base64 and q-p message
decoding
Barry A. Warsaw
barry@zope.com
Sun, 16 Sep 2001 03:19:39 -0400
>>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes:
>>>>> "BG" == Ben Gertzfield <che@debian.org> writes:
BAW> I really like what you've added here, and intend to merge
BAW> those into mimelib. First a couple of general comments and
BAW> then some specific ones.
BG> Great! I appreciate all the comments and the quick
BG> attention. I hope I'm not being a pain, sending off all these
BG> rapid-fire patches. *grin*
Not at all! I've just got to stop trying to respond to this stuff at
3am and Get Some Sleep. ;)
BAW> I wonder if we couldn't generalize some of this into a
BAW> "subpart walker", a la os.path.walk()? I'm not going to do
BAW> that now, but it's something to keep in mind for later.
BG> Yes, eventually this should be generalized into something that
BG> will simply decode even non-text attachments (and even replace
BG> them with Image/etc objects? Hmm.) but I wanted to get
BG> something done now.
Agreed.
BG> Pipermail is not wholly bad, but it is extremely inefficient.
BG> Since so many people are never going to use anything but the
BG> built-in archiver, I'd like to make it pretty solid, including
BG> behaving well on huge lists.
And I applaud you for that!
BAW> Awesome! I hope you don't mind that I changed this message
BAW> just a little bit:
BAW> [Non-text (%(type)s) part of message omitted, filename
BAW> %(filename)s]\n
BAW> Also, is the trailing newline necessary?
BG> Looks fine! I expected lots of things to change.
:)
BG> The trailing newline is an issue I wanted to address;
BG> currently, multiple text parts just show up one after another
BG> (if there was a newline between them in the message, they have
BG> newlines between them).
BG> I'd be happier doing something like how Gnus shows multiple
BG> attachments in a message:
BG> (snip here)
BG> This is the first, text part of the message.
BG> [3. Interesting test --- text/plain; test]...
BG> This is the (second? third?) text part of the message after
BG> the first text attachment.
BG> [5. Interesting pic --- image/gif; gm-icon00.gif]...
BG> This is the (third? fourth?) text part of the message after
BG> the GIF image.
BG> (snip here)
BG> Now, we're already replacing non-text attachments with a
BG> message, but it'd be nice to announce text-attachments too, so
BG> things don't get confusing.
I think I'm too tired right now to parse this, but I'm happy to leave
the newline in for now.
BG> Also, I forgot to test what happens with text/html parts.
BG> Will they get HTML escaped or will they mess up the document?
I'm not sure at the moment.
BAW> I'm going to simplify some of the implementations when I
BAW> check them in, and I may also change the method names,
BAW> although perhaps I should keep yours for `backwards'
BAW> compatibility?
BAW> Side note: the naming scheme in mimelib.Message is getting
BAW> both inconsistent and clumsy. I intend to rectify this when
BAW> I merge it into Py2.2. Question: is backwards compatibility
BAW> with mimelib 0.x important?
BG> Please, please, go ahead and change all the names! I actually
BG> agree that mimelib.Message is a big old mess, and the
BG> get_foo_bar vs. getfoobar functions kind of got on my
BG> nerves. :) I have no attachments whatsoever to the current
BG> names, but I think it would be the right thing to do to at
BG> least make the old names call the new ones (just segregate
BG> them in the documents as a list of compatibility interface
BG> names).
I'm going to keep the inconsistency for now, but will clean it all up
when I merge it into Python 2.2. mimelib 0.5 will also have a couple
of methods that are in the wrong module, but again, that'll be cleaned
up later.
BG> I guess my concept was the reverse; since a "payload" from
BG> mimelib.Message can be either a list of payloads OR a single
BG> message, my brain called the former a "payload" and the second
BG> a "body". But I still don't really know the right
BG> terminology..
BG> We should probably come up with some clearer nomenclature,
BG> because the current one really confused me. :)
BG> Rereading RFC 2045, I see that I subconsciously got my naming
BG> scheme from a past reading of it. Here's what RFC 2045 has to
BG> say:
I'm going to ruminate on this and I'll get the story straight for the
merge into Python. But I think you have some good points.
Thanks!
-Barry