=- 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.