On Sun, Oct 21, 2007 at 05:15:10PM +0200, Rado S wrote: > 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? What's so difficult to know? Mutt is a text-based Mail User Agent geared to the power user of E-mail, with its major goal being to suck less than the other mail clients. It says the latter explicitly on its home page. Inasmuch as it does not implement standard features offered by other clients, it is a failure in that goal. PLEASE NOTE: a power user of e-mail is not necessarily a power user of *anything else*. > > business, so in this single case: Yes. > > ... as stated elsewhere: adding up has more of an effect than just > the sum of its parts. This is not a reason not to do something. > And this total effect can be bad despite all the partial good > effects. This also is not a reason not to do something... It is, however, a good reason not to do something badly. Integrating support for this feature into Mutt is, from the user's standpoint, unquestionably the better way than relying on hacks which are not well-implemented or poorly integrated into Mutt. For a good example, try using Pine with encryption. It's possible, but (unless it's improved a lot since last I tried it, which I doubt) it's absolutely horrible. And the precise reason it's horrible is because support for it is not properly integrated into Pine. > 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. That's not the point at all. The point is that the feature being missing in Mutt is forcing some people who use Mutt in business, and want to continue to do so, to move to something else, because the features they NEED -- features supported by virtually every other mailer in the known universe -- are missing from Mutt. Some of those users might be willing and able to implement the needed functionality themselves... But you would (obviously) be surprised by the number of people who use Mutt who can not or don't want to. > Just because you know when somebody has seen a mail 1st time, it > doesn't mean it will be processed faster thereafter. This is not why return receipts exist. They exist so that the receiver can say, "I know you saw my e-mail, I have the return receipt." It's about accountability... it's the same reason the post office offers registered/certified mail. Mail (both kinds) is inherently unreliable -- you send off your e-mail, and you have no way to know if the recipient actually received it... unless they're using some return receipt feature. Then, the recipient can not say, "hey, I never received your mail." The sender has proof that he did. > 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. Mutt does not have return receipt support. Let me emphasize that: MUTT DOES NOT HAVE RETURN RECEIPT SUPPORT. Mutt has support for letting the user customize and extend mutt in a variety of ways. This is very much NOT the same thing as having return receipt support. Having support means that the user does not have to engineer his own solution, or go digging to find one. It means it's already there, waiting for the user to use it. If it requires the user to code logic (as opposed to simply turning on settings), then it is not supported. Mutt already sucks to configure. It doesn't need any more things for the user to figure out and set up on his own -- not when the feature he's trying to emulate is common in most other mailers. > > 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, On an individual (per-solution) basis, it needs roughly as much maintenance as it would need if it were implemented in Mutt directly; i.e. if the implementation is modular and well-designed, it will not need any significant maintenance unless the way return receipts are handled changes. In that case, your method will require maintenance also. But, your method will not require just 2 or 3 developers to maintain it... instead it will require hundreds or perhaps thousands of users to maintain it individually. Thus however much or little maintenance it will require to maintain in Mutt's source, maintaining an external solution will require exponentially more maintenance. > > 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? This discussion is not about those features. It's about return receipts. Decisions about whether to add a feature can only logically be made on a case-by-case basis. Discussions about drawing lines are pointless and fruitless. From the standpoint of the user, none of your arguments against allowing this feature to be added to mutt are compelling. Even from the standpoint of development, your arguments don't hold much water. Given how little code is likely to be required to support this, and how unlikely that it is that support for return receipts will change in any meaningful way in the near future, the added maintenance from adding the feature is likely to be negligible. You haven't come up with a single technical or logical reason besides this why Mutt shouldn't have this feature. It appears that the only valid concern you have is that you simply don't like the feature. But this is not a defensible reason for denying the feature from the portion of the user community who NEED it. > 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. But not for the next person who needs it... > 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. Exactly the reason to implement features. The only reasons against implementing features which have been brought to bear in this thread are largely emotional, dogmatic, Chicken Little BS that don't hold true in the modern computing world. > > Is your talking representative to all people activeley involved > > into mutt development? Many people (myself included) have been interested in writing code to improve Mutt, but have not done so precisely because the developers are against implementing any new features of any substance (and often even smaller features that require little code or maintenance). Rado, you yourself have fallen into this category in the past. Many (like me) have no interest in writing code for a project, when the expectation is that it will never be included. If we're going to count votes, we ought to find those people and count theirs too. The only thing that gets in these days are small featurelets, unless it happens to be something that one of the main committers particularly cares about. Why is it that virtually all of the major distributions include patches to Mutt that have not been integrated? I believe Mutt would have a much bigger development community if the the current maintainers were to foster discussion about how to design features so that it *can* be integrated into mutt properly, rather than automatically arguing against new features. In this way, the whole user community benefits. This is why the Linux Kernel is such a successful and thriving project, and Mutt hasn't released a new stable major version in over 5 years. Mutt-1.5.1 was released in December 2002. We're on Mutt-1.5.16. On anything resembling modern hardware, Mutt has a lot of room to grow before adding features would present a significant usability problem. It might be that rewriting some of Mutt's core would be required in order to prevent a code maintenance nightmare, but I don't see how having a better core, or providing a framework for new features without causing a maintenance nightmare are bad things for Mutt. Even without a rewrite, it's still possible to add a variety of well-designed and well-written features without causing a nightmare. The addition of SMTP support has, in my mind, proven that the nay-sayers are just like Chicken Little. > I don't see why a soft-coded solution is less reliable, lesser than > any of the other soft-coded (external) solutions. It's less robust. It's less well-tested. It's less well-maintained. The overall amount of maintenance is exponentially larger, since each user must maintain their own solution individually. Most users, even power *e-mail* users, don't want to hack their mailer. There are 5 reasons. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpCG4qdp7XDP.pgp
Description: PGP signature