=- David Champion wrote on Wed 17.Oct'07 at 10:42:41 -0500 -= > If your business environment requires MDN replies, then the upshot > is that mutt is regarded as unacceptable in the business > environment. Nobody wins.
Depends on what you want to achieve: do we want mutt to be acceptable in the business no matter what? (it's not that I believe this single feature would have a significant impact on its own ;) Mutt (as any other MUA) will never suit all, probably not even the majority of potential users. So who to aim for? > But a policy that MDN should not be implemented in mutt per se > because of privacy concerns constitutes an acknowledgement that > scripts, macros, and hooks are insufficient for certain legitimate > interests. If there's a privacy concern, then mutt doesn't support > MDN. You can't get both. Again a simple issue mutated into different directions, all of them not necessarily closely connected. ;) > Someone mentioned that support for MDN with current mutt is "trivially > simple", I think. That depends on how much support you want. That was I, and yes, I agreed with that elsewhere. > It's fairly easy for an intermediate-level user to set something > up that sends an MDN reply on a keystroke, without checking for > whether MDN has been sent before, whether an error occurs, etc. Except for error-checking I don't see what is missing. What error could there be for this case anyway? > I would argue that the net entropy of several people maintaining > varying degrees of hook/script based support for a feature as > potentially complex (for an unbundled add-on) as good MDN support > is greater than the entropy of a single point of maintenance. Certainly, but why is that better? Let it be bundled then (in /contrib or /samples), with cross-references to alternatives for alternative needs (if they exist). > {...} but with the differences among various user environments, > support for all interests can become chaotic even faster than C > code added to mutt, where there's a standard infrastructure that's > already present everywhere by definition. So it is when using a mutt-only-features solution. > I don't care much either way whether the patch goes upstream into > the main code base -- that's a matter of what the maintainers feel > is in demand enough to maintain, ... Before that comes the question whether to follow demand or lead on. > ... and either "yes" or "no" would be a reasonable decision in > this case. Agree. > But I think the argument that it's just as good to do it with > hooks and scripts is either very naive about what kind of support > people would desire, or it's not very well thought out, {...} Hmm, why would the method matter if the exactly same functional result could be achieved? Why does it have to be C-code rather than existing mutt features? If it's mutt, the solution is portable. > All this can be said of any feature proposal, but it's critical to > recognize how much the feature actually benefits from deeper > integration with the mail environment. MDN does. Mowing my lawn > does not. Mowing my lawn should be done by hooks and scripts. MDN > depends on how much you want from it. Right, but please compare it with some "real" equivalents like listed elsewhere (news, filter, spam, mime): the benefit there would be much bigger, or not? Based on what? > Changing people's minds requires logic and empathy -- or radiation > emitters -- so unless someone's hiding some creepy isotopes I'm > not sure we're getting anywhere anymore. This really is up to the > level of being a maintainer decision. If I didn't provide that, I hope at least it qualifies to produce such a decision. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.