nmh-workers
[Top] [All Lists]

Re: [nmh-workers] Novel Definition of Deprecation.

2019-07-25 10:57:39
Either it should be deprecated, or axed in a release without
forewarning.  And if the latter then is that agreement we can do it for
other things too?  After all, many users don't read the release notes
and thus miss the deprecation warnings, or they upgrade several of our
releases in one bound due to their distro, etc., striding differently,
so a feature is effectively axed for them without warning anyway.

Sigh.  Ok, you caught me on this one.

But ... in my defense, Content-MD5 is a giant steaming pile of poo
and I would argue strongly that it's good that it's gone.

First, this has been discussed being removed since 2013.  People
have argued that they have a use, and at first I was like, "Ok, sure,
keep it if people are using it".  But ... those arguments upon closer
look don't (IMHO) make a lot of sense.  Here are my arguments for getting
rid of it, from the last time I brought it up:

    https://lists.gnu.org/archive/html/nmh-workers/2018-07/msg00003.html

I mean ... can you muster a good argument to keep it?  I haven't
seen one yet that wasn't kind of vague, "Oh, I think it's good to be
able to check integrity", but since we're the only ones who generate
it or verify it, that doesn't seem enough justification to me.

Now, some people may say, "Oh, leaving it in doesn't harm anything".
Well, having been inside of nmh a lot I feel strongly that this is
wrong.  The INTERNALS of nmh are a mess.  The Content-MD5 support
was embedded at a bunch of weird layers (like in the base64 encoding
and decoding routines), and I understood WHY it was there, but it
makes maintenance a nightmare, because when someone looks at that code
they have to understand what is going on, and that takes time where
they COULD be doing something more useful.  Also, in the future where
I complete the Great Mime Rewrite there's no way I would implement
Content-MD5 (see above for the reasons why).

Okay, fine, I understand your complaint isn't really about the removal
of Content-MD5; your point is that I didn't really follow the normal
rules about deprecating the support and instead I just axed it.  I have
to plead guily there.  But at my sentencing hearing I would argue that
there were mitigating circumstances; namely that Content-MD5 support
is essentially useless and we are better off without it.  Does that
justify getting rid of it without going through the normal deprecation
schedule?  Well, I'll let others decide that.  My thinking was that for
the few users that still have -check in their .mh_profiles they will
hopefully see the change in the release notes and remove those flags.  I
didn't view it as harming anything because the only people who actually
generate or check Content-MD5 headers are nmh users who have -check in
their profiles and having those switches be nonfunctional won't really
change nmh behavior for them.  I have to believe that only a tiny number
of people are actually doing that now.  If you are suggesting that we
just go whole hog and remove the -check and -nocheck flags that now do
nothing ... well, I can live with that.

As for other features ... well, if they are in the same boat as
Content-MD5 then I am fine with treating them the same way (but really,
that'a a special case and I can't think of anything close to that).
Otherwise we should follow a normal depreciation schedule.

I guess in summary: "Yes, Your Honor, I killed Content-MD5, but he had
it coming and I'd do it again!".

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>