Mail::Box was designed to start with EVERYTHING which the RFCs specify, and ALL uses I know with e-mail. A very high level library. And that's quite a lot... And therefore suffers all the same problems as other large modules (like Tk) have: they are hard to understand when you start with them.
- are you happy that you chose to implement Mail::Box in Perl? Was it a clear favorite in terms of language choice?
- was vanilla Perl-OO enough for you? did you consider a prototype-based or role-based or delegation-based approach to implementing Mail::Box.
- I am very pleased that such a complete package is available for free. I used it to write a daemon which would be emailed Excel spreadsheets as attachments. I used Mail::Box to strip the attachments and apply a number of business rules to the attachments and then email the sender back a clean sheet (with fixed rows) a dirty sheet (with rejected rows) and the original sheet. For reliable daemon creation, monitoring and automatic restarting I used daemontools as I saw nothing in the Proc:: TLNS that looked useable.
- it seems that instead of volunteers to ease the burden of your API usage/docs, people are trying to pull the rug out from under you by populating the Email::* hierarchy... oh well.
