simple example of mimelib? and embedding (not attaching) images in email sent with python.

[phil hunt]

On Tue, 14 Aug 2001 23:12:35 -0400, Barry A. Warsaw <barry at zope.com> wrote:
>
>>>>>> "S" == Stephen  <shriek at gmx.co.uk> writes:
>
>    S> I've looked through the archives regarding using smtplib and
>    S> the numerous MIME related modules for sending email messages
>    S> with attachments.  I've found various solutions, some of which
>    S> no longer seem to work, and was quite surprised how this
>    S> seemingly banal task has caused so much trouble.  However, in
>    S> Microsoft Outlook, it's possible to embed image files into the
>    S> actual message as opposed to having them attached.  This way,
>    S> they display when the recipient views the message.  Just how
>    S> does one compose a message like that with Python may I ask?
>
>It's actually fairly easy using mimelib.  Note that
>
>    http://mimelib.sf.net
>
>contains a pretty up-to-date description of the library API, but it is
>missing an examples section.  That's on my to do list.

I think an examples section would be a very good idea. 

I also think the library would benefit from being conceptually oriented
from the user's point of view rather than the implementer's. I'll give you
an example of what I mean:

To create a new Message (object representation of an email message)
from a string containing the message one does:

msgStr = """From: philh at comuno.freeserve.co.uk
To: barry at zope.com
Subject: this is a message

...body of message here...
"""

myParser = mimelib.Parser()
msg = myParser.parsestr(msgStr)
# (msg) is a mimelib.Message

What's wrong with that? The user has a string, and wants to make a
Message from it. He should be able to say:

   msg = mimelib.makeMessageFromString(msgStr)

and mimelib should sort out the details itself. Instead, the user is
forced to think in terms of the implementation detail of how mimelib
parses text. Note also that this is documentted under the heading
"Parsing MIME documents" which wants to be changed to something like
"Parsing Mail Documents".

I realise that in itself this isn't that important, but I think that
most of the python libvraries would benefit if when defining the 
library's interface, the developers thought in terms of how the users
are going to use it, *not* in terms of how they are going to implement 
it.

(Having said this, I realise that I've made the same mistake in several
places in my mailheader[1] library; these mistakes will be corrected in 
the nextb release).

Incidently, did you look at the mailheader.py code I sent you? Did
you find any ideas in it worth using?

>    S> Also if I read between the lines of some posts in the archive,
>    S> is it safe to assume that mimelib is the way to go for future
>    S> MIME manipulation?
>
>That's the intention.  Guido has given me the green light for adding
>mimelib to Python 2.2's standard library, and I intend to work on that
>over the next several days.  I've got a few bugs and improvements to
>work out, and a little bit more documentation to right, but I think
>it's quite useful as is.  I also think it has a flexible enough
>architecture to provide room for expansion as time goes on.

Is it going to be RFC2822 compliant?

>One question though: while I original wrote mimelib to handle the
>MIME-specific tasks, it really is shaping up to be a general mail
>handling library.  "mimelib" might be the wrong name for it.
>"maillib" and "emaillib" seem inelegant, and "messagelib" too
>generic.

Mail messages and usenet messages are rather similar. Similar enough
that they ought to be represented by the same class (or perhaps, 
different subclasses of the same superclass). This way, once a 
Python programmer has learnt how to do mail messages, they won't
need to separately learn how to do news messages.

If one library covers both, then messagelib seems an approprate name.
(Or mailnewslib, perhaps, even though it is unwieldy).

Also, consider smtplib and nntplib. Successors to these should be
able to communicate using mimelib.Messages as their parameters.

> So while mimelib will be able to replace even rfc822.py (at
>least at the API level initially, perhaps later at the implementation
>level too), we may just have to live with the misnomer, unless someone
>can come up with a good -- not too clever, but descriptive -- name.

I fail to see anything wrong with maillib.
    
>That's part of the trouble with examples in the documentation: they
>can be pretty long-winded.  But that's no excuse for not including
>/something/ to give you a feel for how to use it.

I personally prefer documentation that gives the examples, then
goes on to explain the details.

- - -
[1] mailheader is my attempt to do what Barry is doing with his
mimelib library: provide a Python library for handling email
messages. ("mailheader" is actually a misnomer due to the fact
that originally it was just a MailHeader class). Mailheader was
written as part of my Herbrip email encryption program. It's
conceptually a lot simpler than mimelib: this means it doesn't
understand MIME, it also means it is (hopefully) simply to 
understand.

If you want to look at mailheader, download Herbrip from
<http://www.vision25.demon.co.uk/oss/herbivore/herbrip.html>
and look at the mailheader.py and utility.py files.

-- 
*** Philip Hunt *** philh at comuno.freeserve.co.uk ***
"Welcome to 21st Century America, where the profits of the major 
record labels, movie houses, and publishing companies are more 
important than First Amendment rights." -- Bruce Schneier