[Haskell-cafe] Re: Should Yesod.Mail be a separate package?

[Yitzchak Gale]

Michael Snoyman wrote:
> [1] http://hackage.haskell.org/package/mime-mail

Great news! This is an important package.

It's obviously very preliminary, though. This is not
trivial to get right - look at the long and colorful
history of the Python email library, detailed on the
first page of the library documentation.

Here are some initial suggestions for improvement:

1. The module name Network.Mail.Mime
is too generic. There will also be a parser someday.
We should have Types, Parse, and Render in
separate modules. I expect each of those to grow
gradually as more features are added.

On the other hand, I think I like the decision to
re-implement just the features of RFC 2822
message format needed for everyday MIME
use rather than building this on top of a more
generic message type, as is done in Python.
It simplifies things.

But are multi-line headers supported properly?
That's trickier than it looks, there have historically
been many wrong implementations out there.
That itself could be a reason to build this on top
of a proper RFC 2822 implementation.

2. mailHeaders should have an Ord instance that
compares case-insensitively, though the underlying
Strings should remain Strings.

3. It should be possible to control whether text
parts get quoted-printable encoded. Perhaps add
QuotedPrintable to Encoding?

4. I don't like having those sendmail things here in
the same module and package. It's convenient,
but messy in several ways - creates a spurious
dependency on process, only works on certain
platforms and even then with possible weird platform
dependencies, etc. I think this should be in
a separate package. Once there is a nice
easy-to-use SMTP companion package, I
don't think the sendmail things will be used
that much anyway. Put them in a separate package,
but mention it in prominent places so people
will find it.

5. Is the blaze-builder dependency necessary now that
Bryan has built those techniques into Data.Text?

6. Are I18N text-encoded headers supported? That's
very important, even for simple everyday usage.
It's a bit complicated, though. That might be another
reason to build on top of a full RFC 2822 implementation.

7. This very simple interface is great for everyday
use. Think about how to add the less common
options for more general use, without cluttering up
the everyday interface - custom parameters for
Content-Type and Content-Disposition, specifying
the boundary rather than allowing it to be generated
automatically, etc. It's important to think about
those kinds of things now, before the interface
gets set in cement.

Thanks,
Yitz