And we can't forget that we always can learn with the already existent art.

Cheers

Graciliano M. P.
"Creativity is the expression of the liberty".

The only one of these that I have reservations about is Mail::SendEasy. I'm not real convinced that ripping the guts out of MIME::Lite, Net::SMTP and the rest (metaphorically speaking) and putting them in one place is the wisest idea. For me it violates a bunch of rules. 1)Tools should be simple and single purpose. 2)Tools should be easily usable independently. 3)Code shouldnt be duplicated unnecessarily.

You say that the dependencies are too large for your taste. For me that is a sign of a robust design. Each dependency can be maintained independently by people interested in the relevent field. Net::SMTP handles authentication, MIME::Lite among others handle attachments of a whole range of type correctly and automaticaly. (Meaning it will auto detect the file type and map it the appropriate encoding and MIME type.) M::L can even be used with OpenSSL to create S/MIME mails.

I guess the reason im writing this is that over time my intention with MIME::Lite is to do the exact opposite of what you are doing with SendEasy.pm, that is to move as much of the internals in MIME::Lite that are implemented by stand alone packages into simply using the packages. I say this becuase when I inherited MIME::Lite (which is a very old module) there was all kind of code in there that handled various issues reasonably well but nowhere near as well as the dedicated modules can and do. So for things like email addresses it has code inside it that parses them, but not quite to spec. Wheras it can also call out to Mail::Address and have that parse the address code. Now I dont have to stay on top of the MIME RFC's as well as the SMTP RFC's. And when those RFC's are updated or enhanced, or the author of that module improves his code my module and the all the users of it benefit. Also when you think of testing and exposure using your module represents a severe risk. Your code is new, untested in the wild wheras Net::SMTP and friends have been tested on tens of thousands of machines and work on every platform perl runs on. How many years and bugfixes will go by before we can have the same confidence in your code?

So from my perspective your Mail::SendEasy is probably a maintenance problem waiting to happen. You have to maintain compatibility with something like 6 or maybe 8 different RFC's. Thats a lot of work for a single volunteer author, and I wonder if its really wise to trust production systems to such a tool. I am much more comfortable trusting lib-net which is maintained as part of the core now iirc, Mail::Address for address parsing, MIME::Base64 for base64 encoding (also now part of the core), MIME::Types for mime type detection, etc etc. First off there are less single points of failure (if you get hit by a bus your user base will S.O.L., and given the modules ambitiousness its unlikely to be maintained by someone else), second I believe that by choosing smaller problem spaces to work in the result is more likely to be well maintained.

So, in short I believe that this one module represents what I consider to be the worst reasons to reinvent the wheel.

I will say that i like some of your other work quite a bit though.

You say that the dependencies are too large for your taste. For me that is a sign of a robust design.

Playing Devil's Advocate: there are times when you can go way overboard with dependencies. For instance, Crypt::OpenPGP depends on a huge number of modules, including Math::Pari. Math::Pari is based on the pari C library, which is extremely touchy to compile. When setting up a new system, I often have to restart the pari compile a couple times (usually, the pari binary packages for my system aren't up to date enough). Once installed, Crypt::OpenPGP works quite well, but the Math::Pari dependency is always a pain.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Well, you can be right in some parts, but I had a demand for a long time for a tool that have everything in one package.

Also, to implement Mail::SendEasy, I haven't implemented a full SMTP handler, or a full MIME handler, since I don't wan't to handle all the resources that this definitions have, just what is needed to send an e-mail with TXT & HTML messages and attachments, through a SMTP server that ask for authentication (what is common in this days). One thing that you can see is that Mail::SendEasy, yes it handle a lot of parts, but it code is simple and small.

You said: Tools should be simple and single purpose.

Mail::SendEasy is simple, and for the user side, it's for a single pourpose, send an e-mail. The final user don't want to know that exists SMTP, MIME, or any other technology, since an e-mail system is all of this together.

Tools should be easily usable independently.

Well, this is the main pourpose to Mail::SendEasy be created. What already exist there wasn't "easily usable" as I need for my users. Actaully before they need to install a lot of things and use a lot of modules together to can have what they want.

Mail::SendEasy is soo simple, that this is the only thing that you need to know to start using it:

  use Mail::SendEasy ;

  my $status = Mail::SendEasy::send(
  smtp => 'localhost' ,
  user => 'foo' ,
  pass => 123 ,
  from    => 'sender@foo.com' ,
  to      => 'recp@domain.foo' ,
  cc      => 'recpcopy@domain.foo' ,
  subject => "MAIL Test" ,
  msg     => "The Plain Msg..." ,
  html    => "<b>The HTML Msg...</b>" ,
  anex    => ['/tmp/file1' , '/tmp/file2'] ,
  ) ;
  
  if (!$status) { Mail::SendEasy::error ;}
[download]

Code shouldnt be duplicated unnecessarily.

Well, we can't make everything perfect (first thing that we learn in the life), for one side we win, for the other we lose, and what really matters is the final product.

You complain that maintain Mail::SendEasy is hard and my code wasn't tested as Net::SMTP and MIME::Lite. Well, if we know what we are doing, this point of view is just an excuse to not do things. First, I have based my code in what is already there, what was already tested. Also I have 10 years of experience in Perl doing things much more complex than just a simple mail tool that I build in 2 hours, since I was tired to spend 1h installing modules and checking the behavior of the last version of each module, each time that a system need to send e-mails. But I really respect your opinion, since is your own opinion, build by your self, and in this days is hard to find people that care about that. in this days people just want to use and say what the others says.

From my point of view, use a lot of different modules to do one thing is always hard, one beacuse the user need to learn 3, or more tools, before start doing anything (like in Java), and Perl is to be pratical. Also all of us know that a lot of dependencies, make a module to have a high probity to not work in the future (history show this easy), or to have bugs, since each dependencie cover an area bigger than what your main pourpose need.

Well, Mail::SendEasy is there, and I know that it's in use in Europe by a big ISP to send e-mails. Also I know that it's in use by a FanClub to send more than 300.000 e-mails in one shoot. Soo, it's working for big demand too.

Graciliano M. P.
"Creativity is the expression of the liberty".