Re^2: Reliable software OR Is CPAN the sacred cow

[Asim]

Most of your misunderstand me.

May I make a suggestion? That's not because we're dense. It's because you're bandying about words like "reliable" and "RFC compliant" without defining what you mean by them. And no, your code doesn't count, because, frankly, you're sitting on it. Why is it not on CPAN, if you've made such great strides in the programming realm?

I read your original post yesterday. You utterly confused me, and I suspect a lot of people, by saying it must conform strictly to the RFCs...except that it must also understand mails that are not compliant with the RFCs.

I've seen no links to bug reports from you on these modules. No precise definitions as to the problems you see, so we all can follow along -- few of us have the time to parse through a near-dozen RFCs and the 600+ modules in question, and you, apparently, already have this information. No commentary that you're willing to talk to the various maintainers of the modules about how you might improve them -- which is, after all, the point of Open Sourcing one's code. It's really not to come on a public source, like this, and bash the hard work of many before you.

Let me ask you this -- have you actually talked to any of the developers, or asked for insight as to why they didn't conform to the RFCs? They are, after all, only Requests For Comments. I had a similar issue when I was developing an application to work with ICal files -- the RFC for ICal, and the reality on the ground with regard to Outlook's ICal files, was two slightly different things -- and it was folks from MS that wrote the damn spec! Naturally, I opted for interoperability over adherence to spec, and I strongly suspect you'll find the various Mail maintainers have done similar.

If. You. Ask. And no, asking on Perlmonks does not equate to asking maintainers of modules.

There no replies like: "Yeah, sadly, but there no reliable email parsers on CPAN now.

Sure there are. The problem is, you have a very narrow, and likely unrealistic, definition of reliable. That's why we keep not answering your question; we're trying, very nicely, to point out the reality, based on people using these modules in Real Life situations -- the kinds where security holes, non-RFC compliant emails, etc., are ripped apart very, very quickly. You can either take that advice, or insist on conformance to specs and buzzwords. Your choice, mate.

Ranting on here about "reliability" (which you've also failed to define, aside from some arguments about "Object Orientation" and "Security First!") isn't going to solve the problem, either. They are, in the end, just words -- as Microsoft's "attention" to Security in their products prove. Following the RFCs does NOT equate to a secure product -- and if you don't mean to co-mingle the two, please write so we can understand what you mean.

If you think we're idiots who cannot write code, point out the lines of code that suck in the mail business. That way, we can actually solve problems, rather than play "whack the mole" with your issues and suggestions.

I’m sorry for the rant, and I tried to be as nice as possible. But I’m utterly frustrated that you’re not listening to very good advice, the kind I wish I’d had access to when I first started working with Mail in Perl. I strongly recommend a listen, and deep re-read, of the commentary both here and in your original post. And then to ask deep questions, over insisting that your programming knowledge exceeds those who wrote the various modules, as well as those of us on Perlmonks.

EDITED to clarify programming issues

[powerman]

The problem is, you have a very narrow, and likely unrealistic, definition of reliable.

Hmm. Very interesting. Maybe you right, maybe... but ... can you explain what's wrong with my definition of reliable?

As least few people in the world develop reliable, by my definition, software - DJB, as example. For me it looks like problem isn't in "unrealistic, definition of reliable", but in people who doesn't try to develop really reliable software. They doesn't try, and so they doesn't got it.

Anyway, I'm really interested in your opinion on this topic, so I hope you'll reply. Only few monks reply "on topic" here (and I agree it mostly my fault - I've mixed too many different topics and emotions in otiginal post), so every "on topic" reply I really appreciate.
I'm here not to just rant my opinion, but mostly to calibrate it.

That's why we keep not answering your question; we're trying, very nicely, to point out the reality, based on people using these modules in Real Life situations -- the kinds where security holes, non-RFC compliant emails, etc., are ripped apart very, very quickly.

I can't understand.
If you think existing modules are reliable, because they support all possible cases, both RFC compliant and Real Life - then why you doesn't reply on my yesterday quesion with names of such modules?
Or you think existing modules are reliable, even if they doesn't support some emails (which comply to RFC!) because authors/users of these modules doesn't received such emails?
Or you mean something else?

[Anonymous Monk]

You complain about mbox storage format, but there is no RFC for mbox