Sorry, I'm not on the list, but got this passed on... > >Date: Mon, 26 Jan 2004 13:49:29 -0600 (CST) > >Subject: Re: New module Mail::SendEasy > > > >On Mon, 26 Jan 2004, Simon Cozens wrote: > > > >> [EMAIL PROTECTED] (Yves Orton) writes: > >> > Besides this is there really any reason for yet another MIME::Lite > >> > replacement? > >> > >> Yes, there is, but Mail::SendEasy isn't it. :) See > >> http://simon-cozens.org/draft-articles/email.html for a pretty > >> rant about the current state of mail handling modules.
I have looked through this document. It's a pity that Simon never came to one of my talks on YAPCs, to grasp the basic concept of MailBox. He's quite far off. But of course, he feels the need to insult other people's work to promote his own. It's his way of gaining importance. > >I think your article sort of misses the point. You spend too much time > >ranting about amount of code and slowness, but I think the _real_ problem > >with Mail::Box is twofold: Slowness is not an issue at all, for MailBox: the target is quality. It is rarely needed to proces hundreds of messages per second, and if you need that, Mail::Box is not the module of your choice. > >- Not so great API. The API isn't so bad that I'd call it awful, but it's > > inelegant and bulky, and definitely doesn't make simple things simple. Then please read the tutorial. It shows how simple things can be done. The main user interface is much like Mail::Internet and MIME::Entity provide: (see one of my papers for a more detailed comparison) use Mail::Message; my $msg = Mail::Message->build ( From => 'me', To => 'you', Cc => [EMAIL PROTECTED] , data => [EMAIL PROTECTED], file => 'attach.html' ); $msg->send(via => 'sendmail'); That's not hard to construct and send a fully RFC compliant multipart message. Please start reading the introduction, if the whole is too hard to understand at once... And certainly when you write a paper about the subject. > > OTOH, it _does_ do basically everything you'd ever want for mail > > handling/sending, and if you want to do something complex, it'll do that > > that. That is one of the differences in concept. I prefer libraries to provide a high level functionality. Processing e-mail correctly is very complicated, and I do not expect everyone to read through the 5 related RFCs. I did that, and it resulted in a quite lot of code... e-mail is more complicated to do correctly that most people think. > >- This API problems are compounded by the docs, which are too > > nitty-gritty, and basically treat every method and class as equally > > important. Since there so many methods and classes, this makes it > > really hard to find the bit you need. Depends what you have read. POD is not sufficient for such a large module. Did you take a look http://perl.overmeer.net/mailbox/html/ ? > > The docs also sometimes lack > > important details (like formats of returned values, like is time UTC, > > etc.). Some things are not repeated often enough. It's quite hard to write suffient docs, and 50,000 lines of it is apparently not enough. However, in case of 'time' is repeated on many places that it is in the same format as provided by the time command. See `perldoc time' > > If the docs were revamped to start with a tutotial and overview, > > I think that would go a long way to improving the distro. Have a look at the website, it's all there. http://perl.overmeer.net/mailbox/ > >I'd love to see someone work with Mark Overmeer to take the existing > >Mail::Box code and completely revamp the API. But keep most of the > >internals, because he's dealt with a _lot_ of the niggling corners of mail > >handling, and there's no need to reinvent that wheel. I am open for suggestions, and have even a mailinglist for that. Show me some things you want to code (and how simple it should be), and I will show you the elegance of MailBox's interface. But I'm really fed-up by this FUD which Simon spreads. It's unjustified, coming from ignorance and envy.. -- MarkOv ------------------------------------------------------------------------ drs Mark A.C.J. Overmeer MARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
