On 2012-07-31 12:46:33 -0500, Derek Martin wrote: > On Tue, Jul 31, 2012 at 02:41:07PM +0200, Vincent Lefevre wrote: > > No-one is forced to use sendmail. Is there any advantage of using > > a built-in SMTP-client instead of a standalone SMTP-client? By > > that, I mean: is there any advantage of having a single process > > rather than two different processes? > > Yes, I already more or less gave it, but I'll be more explicit: one > consistent configuration interface, more consistent user interface, > one manual to read. Less to remember, less complexity to manage.
This point is a personal view. Under a context where mail can be sent by several users on the system (even though it has only one physical user), one may want a specific configuration interface and a specific manual for the SMTP part, with a consistent config for all the users. Remember that mail can come from different services, even for end users: cron, diffmon, etc. There's also the case where the user is just the end user of the machine, not the admin, and he doesn't necessarily have the information for the SMTP config if he doesn't want to use the usual sendmail interface. And queue management is better done globally (how does Mutt's SMTP support manage temporary errors due to grey-listing?). What's important is that the user should be able to choose, depending on his use of the mail. If there's a single manual for Mutt and the SMTP part specific to Mutt, then fine, but the SMTP part should have its own chapter, so that a user who won't have to deal with SMTP directly doesn't waste time by all the SMTP-related features provided by the MUA. Then I don't see much difference between a dedicated chapter and a reference to a separate manual. > > There's also the problem of replying to HTML mail, keeping > > formatting options. An editor would be needed too. :) > > Indeed, but in the GUI world there are already widgets that handle > most of that work for you. This is one of the reasons I'd like a Mutt > GUI, though there are others. It's not strictly required though, but > either way, I think handling HTML mail well really does require direct > integration. Maybe "require" is too strong, but I don't think it can > be done without direct integration and still avoid being clunky. BTW, since the editor is an external process and can be a GUI application, there's something that could be done even before Mutt has a full GUI. > > Even though HTML wasn't designed for e-mail (formatting is nice, > > but there should have been standard specification for quoting, > > attribution and things like that), I think that a partial support > > could be useful, mainly because there is nothing else. > > Well, there is: RTF. But not all clients support RTF, and most users > don't even know about it. RTF??? Don't you mean enriched text (text/enriched)? Well, I think that's even worse than HTML (too primitive, e.g. no table support, and without useful features for mail that are not present in HTML, such as a clear quoting specification) and should be forgotten. Not surprising that it is not well supported. I wouldn't complain if its support were dropped from Mutt. > > But even before having a GUI, I think it would be useful to be able > > to use Mutt without quitting the editor opened to compose a message > > (starting a second instance has drawbacks if one wants to modify > > the mailbox). > > I'm sure lots of people agree with this... I certainly do. Actually, > I may look into adding support for this. Originally I was thinking > you'd need a threaded model to make this work nicely, but that's > really not the case. All you really need is a flag to indicate that > mutt has children it needs to watch, a suitable place (probably in the > input loop) to call wait/waitpid non-blocking, and maybe a couple of > configuration options to tie it all together. It actually shouldn't > be too hard, I think. Mutt could fork a copy of itself to handle > submission of the e-mail, if that would make things easier (it might > or might not). It should be totally doable. Yes. However a threaded model would be needed if one wanted to have several views of a mailbox in several terminals, for instance. There should also be a way to add/remove attachments (from Mutt itself) without quitting the editor. > > > Mutt's area of operation is e-mail... are you saying that submission > > > of e-mail via SMTP is not related to e-mail? =8^) If you take this > > > philosophy to its extreme, there is no need for Mutt at all; you can > > > simply tie together all the other pieces together with some shell > > > scripts! So let's do that... let's disband mutt and instead write > > > some documentation on how to write shell scripts that tie together > > > your editor, fetchmail, and an SMTP agent of some sort, all the MIME > > > handling software, etc.; and let the users all do everything > > > themselves. That's the ultimate ideal of the Unix philosophy... > > > This would certainly be the most customizable option! > > > > There would be no problems with that if all is done transparently so > > that the end user won't notice how this is implemented internally > > (except if he wants to look at it). > > The only problem, in my mind, is providing the user with a functional, > consistent, intuitive interface, for managing most if not all aspects > of their mail handling. You can't do that with a bunch of separate > programs. I think it's possible. If this is about a text config file, programs would have to be written for it, or you would have to use wrappers. If this is about the user interface (front-end), the user interface should be a single program and control all the programs that form the back-end. > > I think that Mutt shouldn't go the Firefox way, where a small problem > > somewhere can make the whole application unstable. > > Sure, but this is always true. With its current design, if mutt ever > has a bug in a feature you're using, it will make your whole > application unstable. Only for features provided by Mutt. Here mail sending/reception, mail filtering, and the editor (to compose mail) are provided by external programs and won't affect Mutt's stability. > This is why modular code design is important: You make your bugs easy > to isolate and fix. A lot of mutt is very modular, but my > recollection is that the last time I looked at the interface bits > (which was quite a long while ago), there was definitely room for > improvement in modularity. Of course, this could (and should) be improved. > I seem to recall thinking that too much > functionality is coded right into the main menu bits. If you have a > modular API for implementing your user interface, it's easy to > completely replace the existing curses-based menu interface with a > GUI, or even something more accessible to people who don't have hands, > as one user was discussing in another thread (possibly on mutt-users, > I forget). Yes! > I'm not suggesting that it should incorporate features for every mime > handler under the sun, and I don't mind the idea that some separate > programs do different things that Mutt needs to do. But your > interface will be much more consistent if as many of these things *as > is reasonable* are provided by Mutt, configured like mutt, with the > same key bindings as mutt, then if they are entirely separate programs > with completely different configuration mechanisms. Consistency is > good. The trick is judging what's reasonable. For instance, nothing prevents powerful editors from reading key bindings from the muttrc. It might not necessarily be more difficult than writing another powerful editor for Mutt from scratch. Of course, if using both Mutt and the editor at the same time became possible, changing a key binding in Mutt wouldn't affect the editor dynamically, unless there's some protocol between them; that's theoretically possible, though. > Mark this day down in history: I think this is the first time ever > that you and I have basically agreed on anything non-trivial. =8^) :) -- Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
