Living in an Age of Excess

Taken with the idea itself, I recently created Email::Sender::Server, an eventual email delivery system. It's purpose is to simply sending emails from applications, doing so by providing a simple creation and validation interface and by handing-off/outsourcing the actual email delivery and error handling to a daemon running in the background.

Having pretty-good knowledge of the Perl ecosystem, I quickly found many libraries that would help me accomplish this massive feat. There was DBIx::Class (using SQLite) for storage and querying, DateTime for timestamping (and working with DBIC), Tiny::Try for sane eval'ing, and many more.

Happy with the results I decided to blog about it and ship a developer's version (0.01_01). As is customary in my personal software release cycle, once the new library appeared on CPAN, I logged into a remote development box to do a "clean" install, run tests, etc. Upon installation I noticed the huge dependency chain (which I seriously forgot/didn't see coming) which left me thinking (after my initial WTF moment), "Who would use this", "This is an awful lot to ask of a developer looking to simplify an application", and "This will not do".

This experience reminded me of a similar experience I had with a client recently who had a pretty strict CPAN dependency policy. This experience also reminded me of the saying that "Excess is the Undoing of all Mankind". So the question remained, How can I make this more approachable and adoptable? So I decided to use as many core libraries as possible with any non-core libraries only recursing with a depth of 1-2 level (I'm trying here people).

DBIx::Class was replaced with a home-grown file-system-based datastore, DateTime was replaced with Class::Date (its lean), Tiny::Try was replaced with good'ol eval (used sparingly), and the object system uses Valdation::Class (because I can, ... and its light-weight and awesome).

The result is (still needs much love and attention) what I originally set out to accomplish, ... a fast, simple, approachable eventual email delivery system that makes sending emails from applications quick and easy.

Give it a go (its not production-ready yet) but I'd love some feedback. https://metacpan.org/release/AWNCORP/Email-Sender-Server-0.12/

-Al

P.S. (with regards to CPAN dependencies), Just because you can, doesn't mean you should.

5 Comments

TIL about Class::Date. Thanks, will be checking it out (yes, DateTime is too big and slow for some use cases).

Replacing Try::Tiny with eval seems stupid to me. It is single small dependency... and are you sure that you covered all the sharp corner cases correctly?

ESS looks pretty neat. I don't 100% agree with the dependencies you removed, but I look forward to playing with this.

If Email::Sender::Simple is not the only module an application uses then these days chances are Try::Tiny is going to hitch a ride into the user’s machine somewhere on the application’s dependency chain… so I’d feel no compunction about demanding that one. It’s in the ::Tiny family for a reason.

And it is not comparable to strict and warnings at all. If you leave out strict and warnings, then at most it is your own code that breaks without notice. If you get your handling of eval wrong then it is your user’s code that will suffer the consequences. So doing eval correctly is far more important than having strictures turned on -- especially for library code, and particularly so if you are shipping it to other people on CPAN.

If you want to audit all your evals carefully and keep all the boilerplate you need in the code, more power to you, of course, just make sure you do get it right.

But requiring Try::Tiny would spare you that hassle and is likely to benefit your users (because your code is guaranteed not to break theirs). For this reason it is a dependency I like seeing on modules I use.

Leave a comment

About Al Newkirk

user-pic ... proud Perl hacker, ask me anything!