Re: How to send a return receipt
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