Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Thu 18.Oct'07 at 20:52:22 +0200 -=
> > 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.
Before we (you or I) can judge what is harm- or useful to mutt, we
both would have to know 1st what mutt is about. I don't know it
(yet), do you?
> But we are talking about a mini feature, thats quiet useful in
> business, so in this single case: Yes.
... as stated elsewhere: adding up has more of an effect than just
the sum of its parts. And this total effect can be bad despite all
the partial good effects. Again, before judging this correctly, we'd
1st have to know mutt's nature/principle to relate "good" or "bad".
Where it's useful doesn't matter much then, since mutt is not
limited in use.
> > (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.
A mailer for "freaks and nerds" == willing to adjust it to personal
needs rather than relying on (hardcoded) defaults; to use it for all
mail needs, including business.
Using mutt's power which it already provides before hardcoding
features (mistaken as "adding", because it is already possible).
But regarding my comment whether or not this particular
return-receipt feature is hardcoded or not, it won't make many
"business mail users" change to mutt, because (my guess) that's
probably not the missing "killer feature" which makes them not
change to mutt so far.
> 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.
a) You're mistaken, there are requests to include a wide range of
functionality into mutt that wasn't assumed to be part of mutt, so
not to need to become a "freak or nerd" to make the separate tools
play nicely together to achieve a given goal, but to turn it into
the single communications killer-application that does all they
want/ need at one place.
b) It is important to _you_, undoubtly I believe you, given your
modus operandi, but still I take it as exception. Even among GUI
mail users I'm unsure people _willingly_ use that feature because
they see a gain in their everyday usecase rather than being a preset
default, not caring enough to change.
Just because you know when somebody has seen a mail 1st time, it
doesn't mean it will be processed faster thereafter. In a
non-automated environment they are rather annoying (to me, much like
TOFU posting, which also is well established in the business world,
mostly because of lazyness to edit properly, because there only the
sender's time/ desire count's, not the receivers).
> > 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? {...} but at least every console-affine user
> should be able to communicate with a gui-using-mua-user without
> significant impact in functionaly.
It's not that I don't want it to, but because users' demands are too
different to be satisfied all by a single tool.
mutt communicates with GUI mailers alright already (and can be
expanded to do what is still missing without hardcode), still there
are many piners out there. They're not using pine because of missing
return-receipt support in mutt. Pine, for example, includes news
support and a GUI-like menu oriented TUI. TB has built-in filter/
sort features. Seamonkey + OL have integrated HTML support.
As long as mutt doesn't offer that, people using those tools for
exactly those features won't switch to mutt until mutt does so, too.
> Well, thats my opinion. As far as it seems, its not yours. Thats
> sad, but it is as it is.
Heh, wrong, I have the same intention to provide required
functionality (like your return-receipts automation), but I see them
already achieved while you don't like the way of doing it.
> > Except for error-checking I don't see what is missing.
>
> Well, its all about integration into mutt. You need a completely
> seperate configuration, ...
Huh, what does "completely separate config" mean when you use muttrc
settings + commands?
> ... you can't ask the user properly if he wants to send a mdn, etc.
What's the purpose of asking him?
To give him a choice.
When the user sees such a msg marked, he _knows_ which choice he
has, he doesn't need to be asked, he can act on his own based on the
knowledge.
But you can enhance the nagging if this isn't sufficient
for you.
> > 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, ...
That can happen with hardcode, too.
> ... missing or errornous utils outside of mutt that are needed etc.
Well, you have to rely on _some_ standard unix backround tools.
Or you want to integrate all the external helpers?
editor, pgp, sendmail (already happened :( ), dotlock, query, ssh
Forced modularization forces people to understand how things work
and to better use their tools.
> 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.
I don't know what you're speaking of.
Our "external" solutions provide notifications of different levels
and ease of use by single key invocation, portability across mutt
versions (works even with pre-1.4) and doesn't need any maintenance,
but if, then doesn't require C-coder skills.
What are you still missing?
> 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.
Uh, once you have it working, there is no maintenance needed
anymore. What do you expect to change?
> > Before that comes the question whether to follow demand or lead on.
>
> In the end the mutt developers decide, but they don't develop for
> themselves, right?
That's the question to which I have no answer yet. :)
> If there is a demand and its possible without a big effort, what
> really speaks against integrating it?
Where to draw the line since (as I already mentioned) there are many
more such demands of integration? Why is this any more worth than
the others?
> > 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.
Maintenance is a non-issue, since it won't change.
Convenience is a non-issue, since once it works as needed, it will
be as easy as you want it to be.
> > 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?
(filters are not automated yet!)
_I_ don't expect anything, but there can be a lot, don't you have
ideas for more MIME convenience? How about getting rid of dependence
of yet another external source of errors: mailcap?
What's your take on SMTP?
MUA != MTA, yet it was integrated, you like that?
Just because stuff hasn't anything to do with _your_ definition (or
mine) of what belongs to a mail client, this doesn't mean others
want to have it included nevertheless, because it makes their lives
_much more_ convenient when it's all done out of _one_ box for them.
They don't care much for what belongs where.
So we're back at whether to follow short-term demand or resist
it to provide some long-term ideals.
> > 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?
I don't know, mostly because there never has been any clear statement
about mutt's policy so far with regard to demand vs. ideals.
> But thats sad, because I can't see a single valid argument for
> double effort for a less reliable solution brought in this
> thread. :(
I don't see why a soft-coded solution is less reliable, lesser than
any of the other soft-coded (external) solutions.
--
© 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.