[Mailman-Developers] [PATCH] mimelib base64 and q-p message decoding

[Barry A. Warsaw]

>>>>> "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