For me, ANY software MUST be developed with these priorities in mind:
1. be reliable: it should do it work correctly (ex. for email parsing task it must support all features defined in RFCs related to email format plus be able to handle non-RFC-compliant emails produced by some buggy software)
2. be secure: it should not allow unauthorized usage
3. next priorities may vary from have a lot features to work fast or be cheaper or have intuitive interface, etc.

So, what's your thesis? Are you complaining that there are no Mail::* modules that follow 100% of the RFCs? Or that 99.9% of the modules on CPAN aren't reliable, secure, etc.? Or both?

Well, this is just a reminder that this is the open source community: We're mostly volunteers. If you wanna write something that'll help you get your job done better, more efficiently, more safely, and if you want to sure that work with everyone else, terrific. If you want to use something that someone else has written, go for it. You can even make your own improvements and maybe even get those improvements included, with the thanks of the authour and the community.

But if you're complaining that none of (for example) the Mail::* modules are totally compliant with the RFCs and want to blame someone, blame yourself for expecting the perfect solution for free. And if you want to do something about, use one of the existing modules and fix it up (see previous paragraph) or write your own, using the RFC. You may not encounter fame and fortune as a result, but if the module works well, the community will thank you and you may find yourself being bought a lot of beer.

Finally, the requirement that a CPAN module have an intuitive interface escapes me a little -- you learn about the module interface by reading the module documentation. I don't know how a module's interface can be made .. intuitive. For example, DBI uses the 'connect' method to create a new database connection object. By the time someone pointed how non-OO this was (of course, it should be a 'new' method, everyone knows that), I'd already been using the 'incorrectly name' call to DBI for years, and thought nothing of it .. but it sure is intuitive.

I'm working on preparing a module for CPAN right now, and it's hard .. because I haven't done it before .. but I thnk it'll be worth it, both for myself and for anyone out there who might use it.

And boy, I'm looking forward to that beer. :)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.