* 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. -- rjbs --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
