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 <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.
---------------------------------------------------------------------
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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.