Michael Snoyman wrote:
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