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. OvermeerMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
