Thanks for the elaboration, Ricardo. I will gladly admit I didn't spend
a whole lot of time digging into the API docs, so a lot of my points
were made that cursory perspective. Certainly not as someone really
invested in the world of email as you are.
I find this similar to my experience with Class::DBI and Rose::DB.
Rose::DB is a bear to learn if you're trying from the CPAN docs. It
wasn't until Randal Schwartz's columns[1] on Rose::DB that I 'got' it.
He first laid out the reasoning behind switching and then guided the
reader into using it. I'm now a big Rose::DB fan.
Perhaps you or someone should publish a similar series of columns
(unless they already exist) that does the same? As someone who is happy
with MIME::Lite, blissfully unaware of its problems and shortcomings and
jammed with work, I'm not inclined to investigate replacements with more
than a cursory glance.
- Jason
[1]: http://www.stonehenge.com/merlyn/LinuxMag/col86.html
Ricardo SIGNES wrote:
* Jason Purdy <[EMAIL PROTECTED]> [2007-09-10T09:17:07]
We use MIME::Lite here a lot w/o any problems and certainly without
thinking it's horrendous. I will say that we don't do a whole lot of
email volume, but there's something about its API that resonates with my
style of coding, moreso than the alternatives you mentioned below.
It has lots of insane subtle bugs that won't bite you for a long time, but when
they do, the insanity will be ... um ... insane.
Here's a good one: a MIME message may not have a line longer than 999
characters before the CRLF. How does MIME::Lite solve this? It silently
truncates lines at 990 characters.
The point isn't, "So fix that!" It's that the module is 3500+ lines of such
code, basically negligent around the edges, so that edge cases lead not to
exceptions, but totally crazy failure modes.
I'm fixing these bugs as I get around to it, but there are a lot of better
options, and I'm just one guy. Trying to get people to volunteer to improve
Mail:: and Email:: code has been a real losing bet. If you want to help,
please join the PEP (emailproject.perl.org) mailing list and join in. There's
also irc.perl.org #email.
I actually evaluated the different options over 5 years ago[1] and while
it seems apropos to update my review, after looking at the API docs of
the modules you mention, I still come to the same conclusion.
The API of MIME::Lite isn't that bad, apart from a lousy implementation of
sending, and conflation of the message and sending interface. It's the MIME
implementation and the guts.
I like to create an object, optionally with some config data, be able to
later set the config date and then call a method upon the object to get
something done.
Sure.
Looking at Email::Simple and Email::MIME: those both look like parsing
emails. So that leaves Email::Send and Email::Stuff.
Please see Email::Simple::Creator and Email::MIME::Creator. Seriously, though,
if you don't know anything about them, why are you trying to say whether
they're appropriate?
Email::Send doesn't have parameterized configuration, which just seems
odd to me. You put together the complete message in one big string and
then Email::Send magically does the rest.
Yes, you CAN do that. Non-crazy people, however, use Email::*::Creator and
then pass the Email::Simple-derived object to Email::Send.
Email::Simple (and subclasses) and Email::Send divide the concerns into
"representing a message" and "sending a message." Email::Send has its share of
problems, and they're being addressed, but requiring you to build a message
string is not one of them.
Again, your assessment here seems to be based on a two minute skim of the
documentation, not a serious amount of work with the modules either as a user
or a maintainer.
Maybe this just means that Email::Simple needs a big SEE ALSO section, or the
like.
Email::Stuff does have parameterized configuration, but it seems to
chain it all together, which, again, seems odd to me.
It combines a lot of other Email:: modules to give you a simple (if quirky)
interface to many of the small, special-purpose modules in Email::.
If you're maintaining MIME::Lite, can't you improve it so it's not
horrendous? Or provide the same API styles for better modules? There's
something to be said about ugly code that's easy to develop with vs.
beautiful code that makes you work harder.
Yes, I could, but I don't see the point. Email::Simple (etc) and Mail::Message
provide good APIs, if you give them a reasonable look. I could try to make it
possible for Email::Simple and MIME::Lite to compete with one another, but that
seems like a fool's errand. I'd rather pick the one that is not currently
brimming with insanity within and make that the best tool.
Of course, patches welcome.
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
