> Humm, MIME::Lite need sendmail or some object instance that
> send e-mails to
> reaally send an e-mail.
Yes thats correct. The composition and transmission layers are logically seperate. But that doesnt change that fact that MIME::Lite is quite capable of using Net::SMTP to transfer mails. And as of 3.01_03 with authentication too.
> MIME::Lite is more to can build the content of your e-mail,
> what is just a part of all the process to send an e-mail.
Well, not really. Its essentially "all you need straight out of the box", given certain platform specific issues. Like libnet on win32, on the presence of something "sendmail" like on non win32 platforms.
>
> By the awy, I use Mail::SendEasy in Win32, soo, I can't use
> sendmail. And we know that the sendmail approach to send e-mails in this days
> is not the best, specially if you want a resource that is platform independent.
Again, this is merely an question of configuration (also convention, many non sendmail mailers use the same command line arguments). With a single line of code you can use whatever you like for the transmission part of the mail. IMO that good design in fact. There is no hard binding of the two layers. MIME::Lite can use anything that accepts the "print" method to use for transport. It really doesnt care.
So in a sense what you have is two reinvented wheels merged into each other. One, is the composition part of MIME::Lite. Second is one of the many tranmsission schemes available for MIME::Lite to use.
Now, my question is this: Why should we assume that your MIME construction is better than MIME::Lites which has been around for practically ever, and has been tested on thousands of machines? Why should we assume that you SMTP implementation is superior to that offered by libnet?
Further, how long will you be around? libnet is actively maintained by it author (a respectable member of one of the largest commercial development shops around), MIME::Lite is maintained by me, but if I lose interest it will be pased on, as it was to me. The module has a large enough following already that this is almost guaranteed.
I dont say this to be rude or anything, just to make the point.
> Note that I have created Mail::SendEasy to be the handler of
> the mail system
> of a framework. Soo, the developer that uses this framework
> doesn't need,
> and shouldn't, care about how the e-mail is sent. It just
> write the e-mail.
Umm, now your saying something different. The developer will HAVE to know about how the mail is sent. He will have to configure the code to use the correct SMTP server, and if he isnt using SMTP will have to configure whatever that is. This would be the same as using MIME::Lite, except that since MIME::Lite uses libnet, as long as the libnet.cfg is configured appropriately about the only thing you have to do is tell MIME::Lite to use SMTP to send, and that requirement only on *NIX systems where SMTP is not the norm.
> Also it handles SMTP AUTH, one of the purposes that I have
> wrote it, since
> our main Web Hoster, for security, need authentication to can
> send e-mails.
Yes. Im aware that this is becomming an ever more common requirement of SMTP servers. Hence MIME::Lite 3.01_03 is dev release of Autheticating SMTP server friendly MIME::Lite.
> Well, as you can see, the main purpose is to have all this
> resource in one self contained package.
Which doesnt seem like either a good idea, or a real benefit.
Transport != Composition. So why should the two be hard bound?
Yves
