Hi, On Wed, Oct 17, 2007 at 10:30:07PM +0200, Rado S wrote: > Depends on what you want to achieve: do we want mutt to be > acceptable in the business no matter what?
if we were talking about anything thats very harmful to mutt in general I would say: No. But we are talking about a mini feature, thats quiet useful in business, so in this single case: Yes. > (it's not that I believe this single feature would have a > significant impact on its own ;) Well, what do you consider mutt to be? A mailer for some freaks and nerds that just communicate with each other, or a solution for communicating via email, what includes business needs. Off course it is a mailer and not a PIM or something, so one would never expect mutt to support groupware functionalites but in this case we are talking about a quiet important just mail-related function. > Mutt (as any other MUA) will never suit all, probably not even the > majority of potential users. So who to aim for? Why? It is a mail program. Why shouldn't it support a majority of potential users? Okay, lets not say a majority of users, because that would mean mutt would need a graphical gui and be fully integrated into desktop environments, but at least every console-affine user should be able to communicate with a gui-using-mua-user without significant impact in functionaly. Well, thats my opinion. As far as it seems, its not yours. Thats sad, but it is as it is. > Again a simple issue mutated into different directions, all of them > not necessarily closely connected. ;) You are right. But thats the cause of people argumentating in a way, thats far from reality. I'm sorry, but those arguments came mainly from the opposites of this feature-request. > Except for error-checking I don't see what is missing. Well, its all about integration into mutt. You need a completely seperate configuration, you can't ask the user properly if he wants to send a mdn, etc. > What error could there be for this case anyway? I could imagine a lot of things that could go wrong, when using an external script for MDN. To name a few: Problems with the mail headers, missing or errornous utils outside of mutt that are needed etc. All in all its neccesary to rebuilt a common framework inside of a script again, which is already a part of mutt. Causing duplication and possibly reintroducing problems that were already solved in mutt. > Certainly, but why is that better? Because the external solution will always hink after mutt, the maintainance needs are a lot higher, as a one-time integration into mutt source (because further changes are just streamlined into the normal development process), etc. It is simple: Offcourse it is possible, but there are a lot more cons about implementing it outside of mutt, then pros to keep it out of mutt. > Let it be bundled then (in /contrib or /samples), with > cross-references to alternatives for alternative needs (if they > exist). That makes it easier to get it, but not to maintain it. > So it is when using a mutt-only-features solution. That actually speaks for an integration into mutt, because what you suggest, is _not_ a mutt-only-features solution. > Before that comes the question whether to follow demand or lead on. In practice the best is a compromise between the one and the other. In the end the mutt developers decide, but they don't develop for themselves, right? If there is a demand and its possible without a big effort, what really speaks against integrating it? > Hmm, why would the method matter if the exactly same functional > result could be achieved? See above. You shouldn't ignore the arguments that were told, then you would know that. > Why does it have to be C-code rather than existing mutt features? > If it's mutt, the solution is portable. Again. > 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? You are comparing apples and bananas anyway. Reading news is not the job of a MUA (and there are clients doing that better), filters are already part of mutt through save-hooks etc., spam solutions is not directly related to what a mail _client_ should do and mutt already has good interfaces to it. So there is mime left over: What exactly do you expect from mutt to do in this direction? > If I didn't provide that, I hope at least it qualifies to produce > such a decision. Is your talking representative to all people activeley involved into mutt development? If so, then this dicussion has no sense to continue. But thats sad, because I can't see a single valid argument for double effort for a less reliable solution brought in this thread. :( Regards, Patrick
