Re: Header re-write

[Scott Schwartz <schwartz@galapagos.cse.psu.edu>]

| Then you're volunteering to work on it? 

As I said before, I was one of the first outside of Toronto to run
zmailer and I've already spent umpteen hundreds of hours hacking on
it.

| Seriously though, I'm not sure I understand this whole argument. 

My argument is that good engineering practice is important.  Zmailer
2.2 is effective and stable and so the best use of programming effort
is to repair bugs and improve documentation.   Adding new features to a
stable product should not be done lightly, only after they are
shown to be necessary.  Adding unnecessary features is certain to add
bugs, and generally make maintainance harder, and diverts effort from
the more important work of repairing bugs and improving documentation.
Moreover adding poor features makes the product worse; just tossing
things in is as likely as not to accumulate misfeatures.

| You're maintaining that a piece of software with more features cannot be
| as good as a smaller program, even if the newer version performs just as
| well, or maybe even better than the older one?  

"Features" doesn't mean "good qualities".  2.99 has lots of "features"
that make it worse than 2.2.  Moreover, "performs just as well" is an
unproven assertion.

| If you want to work with a
| product that doesn't have any new features, why not just use MMDF?  

Rayan explained the reasons for that pretty well in the Zmailer
Operations Guide.  If you didn't find his rationale compelling why are
you running zmailer?

| That worked wonderfully in 1983.  

I had the opposite reaction, actually.

| But say you want DNS to be part of the code, not tacked on as an afterthought.  
What does that mean?  DNS wasn't an afterthought in zmailer, it's been
there from the start.  And in any case, it is an essential part of
operating on the internet.  That makes sense to you, right?

| Say you want MIME support.  Are these features that we REALLY need? 

No.  MIME support is a quality of the mail user agent, not the mail
transport agent.  MTAs should transport mail, not quoted-unintelligiblize it.

| So the code becomes more flexible in order to deal with them.  

That would be nice, but maybe the software will actually become more
brittle and less able to withstand stress.

| But it sounds like you're saying that adding more features always
| makes the code less reliable?  That a bigger program can't be better?  

Generally this is true.  At a minimum it means that there is more code
that must be understood and maintained; there is a real cost associated
with that.  In well engineered systems adding a new feature (after it
is shown to be necessary) involves removing some old features, which
keeps the complexity of the system under control when it gains new
functionality.  The localnames thing and the MIME thing are examples of
where this was not done.

| That argument might hold for code on a firewall machine, that has to be 
| checked line by line for security, but that doesn't apply to Zmailer -- you 
| wouldn't run Zmailer on a firewall machine.

If you set low standards you will get poor results.  I prefer that
zmailer be engineered to the highest standards.