Re: [cgiapp] Emailing Results?

[Ricardo SIGNES <suppressed>]

* Jason Purdy <suppressed> [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.

-- 
rjbs

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed