Re: Unix Philosophy (was List management headers)
On Thu 4, Feb'10 at 8:07 PM -0800, Morris, Patrick wrote: Some of us are fans of the interpretation of the Unix philosophy that includes gluing together a lot of small, purpose-built apps into a greater (albeit sometimes messy and convoluted) whole. I agree with this for the most part. Setting up msmtp or putmail.py is easy. If you want a beefier MTA, then you can get into postfix if you want. The ability to choose between mutt's inbuilt IMAP or offlineimap or getmail or fetchmail is also very nice. I'm ok with external utilities like ulrview scraping URLs out of an email, because the flow of information in that case is directed out of mutt. Find the URL, and pass it off based on your mailcap entry, which is brilliant. Mutt's not a browser and shouldn't made to be one. The power of mailcap with it's autoview settings is a testament to the flexibility of this approach. I'm not so sure that model works for the list header thing though. One could certainly write a utility to parse the headers and display them. However, the final action that one takes with the selected output is not to pass it off to a program of your choice based on mailcap, but to send another message through mutt. To me, something like this IS a good candidate to be integrated into mutt. It's essentially a variation on the reply command.
Re: Unix Philosophy (was List management headers)
On Fri 5, Feb'10 at 5:28 PM +0100, Rado S wrote: Well, you want an automated processing, not writing regular mail where you type something. You don't need a MUA for that, you can go directly to te MTA. Good point. Don't know why I didn't think of that. Thanks for that. Though, there are other reasons why you might want to edit the body of the message. If I'm not mistaken, there are commands you can send to some list addresses. Not that anyone uses those...
Re: Unix Philosophy (was List management headers)
=- Tim Gray wrote on Fri 5.Feb'10 at 11:32:59 -0500 -= Though, there are other reasons why you might want to edit the body of the message. If I'm not mistaken, there are commands you can send to some list addresses. Not that anyone uses those... I do, but the interfaces vary, so ... I just memorize what I need and type it when needed. Doesn't happen too often. -- © 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.
Re: Unix Philosophy (was List management headers)
On Thu, Feb 04, 2010 at 09:50:02PM -0600, David Young wrote: Isn't this a problem of packaging, not a problem of architecture or philosophy? It should be evident from the large amount of traffic on this list that it is not. If you've been here long enough, you see the same threads over and over and over and over and over... People asking the same questions about how to do something. They get seventeen different answers -- all valid -- about how to solve their problem... all of which require them to perform something that's not entirely unlike coding to accomplish their goals. If I wanted to write my own mailer, I would have done so long ago... ;-) But, *do not confuse this criticism with a complaint*. I have used Mutt for the last 10+ years, and still haven't seen anything I'd rather use. I think the flexibility that it offers is highly desirable. All that said, what I'm trying to point out is, Mutt can offer that power and flexibility, while still offering seamless integration for a lot of things that people are always asking how to do, and this can not help but make mutt better. There has been a historical tendency to immediately reject such features out of hand, without any thoughtful discussion, because something else is capable of doing it... that's particularly mind-numbing. Do not confuse this criticism with distaste for the Unix philosophy either. I'm a huge supporter of it, and use it daily to guide the tools and solutions I develop for myself and others in my job and personal computing environment. What I do not support is arguing against addition of features that a lot of people would use, just because there's something else out there that *could* be glued onto Mutt to do it, particularly when adding the feature to Mutt would make the functionality smoother and easier to use (compared to glue solutions), providing a better overall experience for the user. Philosophy is fine, but usability is key. I will harp on this point: computers are a tool to make our lives easier. You should not sacrifice ease of use purely in the name of dogma. If a useful feature should be excluded (when there is someone willing to write the code), there should be a strong technical reason for such an exclusion; not simply duh, Unix philosophy!! -- Derek D. Martinhttp://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. pgpaLnkpFDk26.pgp Description: PGP signature
Re: Unix Philosophy (was List management headers)
=- Derek Martin wrote on Fri 5.Feb'10 at 13:13:54 -0600 -= If a useful feature should be excluded (when there is someone willing to write the code), there should be a strong technical reason for such an exclusion; not simply duh, Unix philosophy!! It's resource efficiency: I don't want to always by new hardware just to read my simple text mails. :) For my basics I could be happy with a P1 (or even 386 for that matter) with 200MB RAM. -- © 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.
Re: Unix Philosophy (was List management headers)
On Fri, Feb 05, 2010 at 08:19:01PM +0100, Rado S wrote:
You, however, expect all the solutions to be put into the core
C-code
Not *all*... just the ones that make sense. The Unix Philosophy
doesn't preclude maintainers from using their brains to decide what
features do or don't make sense. Dogma does.
while I suggest keeping it outside wrapped around it (or
plugged in, once we have a plug-in interface ;).
Plugins are fine, but there's been resistance to even adding that.
Those wrap-up solutions can be accumulated and delivered
centrally, too, like on the wiki. It need not be shipped with each
package release. Think of Firefox and it's add-ons.
The fact is, main-line code is much better maintained than code that's
outside the core. Yet another reason in support of monolithy.
The quality of Mutt has not suffered for having {smtp built-in} ...
how can that not mean that Mutt is better for having it?
With this argument you justify _literally_ any feature
Yes, exactly. That's my point. Any useful feature is justified for
consideration... If you have someone willing to write the code, and
the proposed design integrates cleanly, you should need to justify NOT
adding it. Not the other way around. If a feature clearly does
negatively impact performance or stability, or clutters up the
interface, or whatever, then you use your brain to decide not to
include it. Otherwise, there's no practical reason not to. Don't
reject features for no REAL reason. Obviously this is a judgement
call, and the maintainers should decide what is useful or not useful,
what is damaging or not damaging. But the mindset should be to
include features unless there's a legitimate, quantifiable reason not
to.
This mindset is what led Rocco and others to attempt a fork of Mutt a
few years ago, which in turn prompted a flurry of development activity
from Brendan and others. Progress is good.
--
Derek D. Martinhttp://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.
pgpUVbfibsaOF.pgp
Description: PGP signature
Re: Unix Philosophy (was List management headers)
'Evening, Derek On Fri, Feb 05, 2010 at 02:28:06PM -0600, Derek Martin wrote: The performance characteristics are impacted more by mailbox size and by growth of the C libraries linked against, than by any combination of proposed features. Why do you link _against_ C libraries? Surely you link _with_ them, unless you're talking about joining in some sort of conspiracy to suppress their use. Like, if you're in a large folksy sort of dance where everybody links arms with their neighbours in a big circle, you never say they're linking arms against their neighbours. They link arms with them. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -- Alan Mackenzie (Nuremberg, Germany).
Re: Unix Philosophy (was List management headers)
On Fri, Feb 05, 2010 at 09:19:13PM +, Alan Mackenzie wrote: On Fri, Feb 05, 2010 at 02:28:06PM -0600, Derek Martin wrote: The performance characteristics are impacted more by mailbox size and by growth of the C libraries linked against, than by any combination of proposed features. Why do you link _against_ C libraries? Surely you link _with_ them, unless you're talking about joining in some sort of conspiracy to suppress their use. That's perhaps the best point made in this entire thread. :) -- Derek D. Martinhttp://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. pgpNcWolN5lBF.pgp Description: PGP signature
Re: Unix Philosophy (was List management headers)
=- Derek Martin wrote on Fri 5.Feb'10 at 14:39:24 -0600 -=
The Unix Philosophy doesn't preclude maintainers from using their
brains to decide what features do or don't make sense. Dogma does.
Can't you imagine that there is actually some brains behind that
dogma?
I'm all against mindless dogmas, but if the decision is justified,
is it a dogma then? Only to those who don't recognize the
justification for whatever reason. Often it's just a matter of taste
or preference.
Plugins are fine, but there's been resistance to even adding that.
Yes, missing volunteers/ manpower to implement it.
The fact is, main-line code is much better maintained than code
that's outside the core. Yet another reason in support of
monolithy.
Rather than putting all the responsibility on a few better
distribute it more evenly, i.e. grow more volunteers to contribute
in those areas, too.
If a feature clearly does negatively impact performance or
stability, or clutters up the interface, or whatever, then you use
your brain to decide not to include it.
{...}
Obviously this is a judgement call, and the maintainers should
decide what is useful or not useful, what is damaging or not
damaging. But the mindset should be to include features unless
there's a legitimate, quantifiable reason not to.
That's what happens/ed.
Once you let loose and open up the can of worms, then you never can
get them back in; where is the limit, where to draw the line?
This mindset is what led Rocco and others to attempt a fork of
Mutt a few years ago, which in turn prompted a flurry of
development activity from Brendan and others. Progress is good.
Not to forget that fork dried out and Rocco came back to the
original.
Yes, progress is good, when you keep it where it belongs.
Everyone decides for herself where that is.
--
© 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.
Re: Unix Philosophy (was List management headers)
=- Derek Martin wrote on Fri 29.Jan'10 at 17:45:28 -0600 -= There has been a tendency in some quarters to blindly and rigidly advocate that following the Unix Philosophy is the One True Way, which has often hindered progress. What kind of progress do you mean? Maybe your goals or ideal world intentions differ from others, and neither your nor theirs(!) are right for everyone. [although my main point, which I may not have made well, is that using the Unix Philosophy as justification to not implement a beneficial feature in mutt is mostly kind of lame]. If there are no limits, every code will tend towards a massive do-it-all-in-one-app nightmare, wasting resources for every other user not interested in all the supported features for a given task. Think of Mozilla-Suite or OpenOffice scales just to ls -l, what a gain. In potentially a lot of ways, it's just easier for users to deal with monolithic apps. Sure, but then they should go there, you don't have to turn each existing app into such beast, there are enough of them. :) As I said, I believe that if you need to have complexity, it should be in the code, not on the user end. The glue to accomplish complex goals needs not necessarily to be in the user end, it can be put in meta-code (wrappers), which can be constructed by advanced users to share with other user. See, this already happens for mutt. Sure, Mutt has SMTP functionality now, but it took about a decade and a couple of changes of maintainers for that to happen. And I still don't consider it a good decision. :) The benefit of adding this functionality seems so obvious; yet it took forever to convince the devs it was a good idea. This is, IMO, a fine example of where a monolithic application wins, and arguing no way, unix philosophy! loses. I favour the user should know (the basics of) what he does/ uses argument over the user-convenience. The mass of unknowing users not wanting to care for how all the stuff in the background works are free to join the OutLook/M$ crowd by expanding their branch of mutt into OL. Of course, in this case, Mutt could provide its SMTP functionality in a separate program; as long as that separate program is behind the scenes, and the user doesn't need to do anything special to configure it, then you can have your Unix Philosophy and eat it too. Normally this is the case, because normal systems have a functional MTA already or it's sufficiently easy to configure with modern UI menus. Now you can say that it is not normal or easy to setup an MTA as single user, but neither of us can prove what normal is. The advantage of a monolithic app is that, in cases where one is called for, most users usually won't care about those issues, and there's usually a lot less for them to worry about / manage with a monolithic app than with a bunch of smaller programs. Really? You still have to give all the details required for (for example) the MTA part; does it matter that you do it in the big-app on another page or in a separate app? In both cases it is elsewhere, remote to the MUA part. The question is: do you follow the crowd (convenience) or make the crowd follow you (learn how things work)? -- © 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.
Re: Unix Philosophy (was List management headers)
On Thu, Feb 04, 2010 at 09:30:51PM +0100, Rado S wrote: As I said, I believe that if you need to have complexity, it should be in the code, not on the user end. The glue to accomplish complex goals needs not necessarily to be in the user end, it can be put in meta-code (wrappers), which can be constructed by advanced users to share with other user. See, this already happens for mutt. And this is exactly the problem. I'm not suggesting that Mutt should become outlook... I hate outlook. But when you have a requirement that things that are complex be done outside the app, it means: - It's not seamlessly integrated into the user's experience - Users need to engineer their own solutions - Invariably, many people re-engineer the same solution many times It's a monumental waste of effort. It's generally much, much better if someone takes the time to integrate the functionality into the program directly, so that users don't need to keep re-engineering it, or at least hunting down the solution that someone else engineered. Sure, Mutt has SMTP functionality now, but it took about a decade and a couple of changes of maintainers for that to happen. And I still don't consider it a good decision. :) That's only because YOU have no use for it. Lots of people do. The quality of Mutt has not suffered for having it... how can that not mean that Mutt is better for having it? I favour the user should know (the basics of) what he does/ uses argument over the user-convenience. People should know about their tools; that does not mean they should have to trade off convenience. Computers are tools; they're supposed to make our lives easier. You clearly appreciate learning for its own sake. The overwhelming majority of people who use computers don't feel that way about it. The mass of unknowing users not wanting to care for how all the stuff in the background works are free to join the OutLook/M$ crowd by expanding their branch of mutt into OL. It's not that simple. Outlook sucks for a lot of reasons, many of them technical. Mutt has very few technical weaknesses, but its user interface is from 3 decades ago. I, and I suspect a lot of people, would love to see a modern Mutt. The advantage of a monolithic app is that, in cases where one is called for, most users usually won't care about those issues, and there's usually a lot less for them to worry about / manage with a monolithic app than with a bunch of smaller programs. Really? Yes, really. You still have to give all the details required for (for example) the MTA part; does it matter that you do it in the big-app on another page or in a separate app? In both cases it is elsewhere, remote to the MUA part. It matters quite a lot. You ever try to configure sendmail from scratch? To configure Mutt's SMTP functionality, you need only know the answers to a handful of questions. To configure a full-fledged MTA, you may very well need to know a lot more than that. Some MTAs are easier than others... But what happens when it doesn't work? You probably have a long night ahead of you to figure out why. With Mutt's SMTP support, you tell it what smtp server to use, and if it doesn't work, you call your ISP and let them figure it out; the problem pretty much has to be on their end, if your settings are right... The question is: do you follow the crowd (convenience) or make the crowd follow you (learn how things work)? It has nothing to do with the crowd. It has everything to do with reducing the amount of work that I shouldn't need to do. That's the purpose of computers. :) -- Derek D. Martinhttp://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. pgpMDstH6yAq4.pgp Description: PGP signature
Re: Unix Philosophy (was List management headers)
On Thu 04 Feb 2010 at 15:44:08 PST Derek Martin wrote: It's not that simple. Outlook sucks for a lot of reasons, many of them technical. Mutt has very few technical weaknesses, but its user interface is from 3 decades ago. I, and I suspect a lot of people, would love to see a modern Mutt. Some of us *prefer* that 30 year-old UI and the Unix philosophy way of doing things. As somebody else said, you're welcome to fork off a new branch of mutt where you can implement all the modern features you're pining for. Just leave the rest of us the good old mutt that we know and love, OK?
Re: Unix Philosophy (was List management headers)
On Thu, Feb 04, 2010 at 05:44:08PM -0600, Derek Martin wrote: On Thu, Feb 04, 2010 at 09:30:51PM +0100, Rado S wrote: As I said, I believe that if you need to have complexity, it should be in the code, not on the user end. The glue to accomplish complex goals needs not necessarily to be in the user end, it can be put in meta-code (wrappers), which can be constructed by advanced users to share with other user. See, this already happens for mutt. And this is exactly the problem. I'm not suggesting that Mutt should become outlook... I hate outlook. But when you have a requirement that things that are complex be done outside the app, it means: - It's not seamlessly integrated into the user's experience - Users need to engineer their own solutions - Invariably, many people re-engineer the same solution many times It's a monumental waste of effort. It's generally much, much better if someone takes the time to integrate the functionality into the program directly, so that users don't need to keep re-engineering it, or at least hunting down the solution that someone else engineered. Derek, Isn't this a problem of packaging, not a problem of architecture or philosophy? Perhaps a Mutt application doesn't ship complete from Mutt.org, but you have to assemble Mutt and some ancillary software to produce a useful email application. There is probably a Linux distribution that does that for you. I install Mutt from pkgsrc.org, myself; it seems to come reasonably complete that way, but my application may be different from yours. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: Unix Philosophy (was List management headers)
Charlie Kester wrote: On Thu 04 Feb 2010 at 15:44:08 PST Derek Martin wrote: It's not that simple. Outlook sucks for a lot of reasons, many of them technical. Mutt has very few technical weaknesses, but its user interface is from 3 decades ago. I, and I suspect a lot of people, would love to see a modern Mutt. Some of us *prefer* that 30 year-old UI and the Unix philosophy way of doing things. As somebody else said, you're welcome to fork off a new branch of mutt where you can implement all the modern features you're pining for. Just leave the rest of us the good old mutt that we know and love, OK? I'll second that. There are a lot mail clients out there, but my personal opinion is that mutt sucks less than all of them in large part due to that clunky 30-year-old interface and the ability to glue in all those barely-integrated little pieces to do all the stuff Mutt doesn't do on its own. I like that I can use an MTA that's not hard-wired, that I can bypass the horrendous built-in IMAP support, and that I can get really creative with how I handle attachments. I appreciate that nearly all of the functionality, from the editor I use to compose messages to the utilities I use to spit them out to various printers when necessary, are all external tools hand-picked and perfectly suited toward doing what I want them to do. I don't want an MUA that does everything one way, and if Mutt was one of those, I wouldn't be using it. Yes, a monolithic mutt could be easier for most people to use; I can't argue with that. But it's also flexible as hell, and that exactly what I like about it. Some of us are fans of the interpretation of the Unix philosophy that includes gluing together a lot of small, purpose-built apps into a greater (albeit sometimes messy and convoluted) whole. I doubt there's one of us that'll claim that's what's best for everyone, but it's definitely the way to go for people like me. (Disclaimer: I'm on a borrowed laptop at the moment, so don't read the headers on this one.)
Re: Unix Philosophy (was List management headers)
* Morris, Patrick patrick.mor...@hp.com [02-04-10 23:08]: (Disclaimer: I'm on a borrowed laptop at the moment, so don't read the headers on this one.) you don't have a stick with putty on it? For shame :^) -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
Re: Unix Philosophy (was List management headers)
On Tue, Jan 26, 2010 at 12:09:41PM -0600, David Champion wrote: I would love to see RFC2369 handling built in to mutt, but have not had time to explore this in code. I'm certain there are others here who would cite the Unix Philosophy or whatever, and assert that an external program could do this as effectively and with cleaner layering. While such people would not necessarily be wrong, I think this (i.e. the example of handling mail) is a great example of where the Unix philosophy kind of falls down. I've always felt that way, despite being a big fan of the Unix Philosophy. There are a couple of ways to look at this. One is this: the Unix philosophy is to do one thing, and do it well. In the case of my mail program, the one thing is to handle my mail. It should be capable to do all of the essential things that involve handling mail, all of the common things, and most of the less common things. For the rest, ideally it should have nice hooks to make it possible (if not easy). Of course, this encompasses a great deal of functionality. You can implement all of it, and arguably still hold true to the Unix Philosophy. Another way to look at it, if you think that the above idea is stretching the Unix Philosophy beyond what was intended (which it very arguably is), is that the Unix philosoply is about 4 decades old, and software (and users) have long since evolved to a point where it just doesn't always make sense. For an application like e-mail, there *is* a lot of functionality that needs covering. You can either write one monolithic application to handle it all in a consistent way, or you can stick with the ancient philosophy and glue all the bits together in a way that, for my money, eventually gets pretty clunky, or at the very least requires a lot of user effort to get it all working. The small pieces each have their own interface, which often doesn't play well with other peices without some coercing, unless they were designed from the beginning to work together. Maybe it's because I'm getting old, but in this, I value practicality over philosophy. There was a time when I loved tinkering with all sorts of clever solutions to little challenges... But now, all I want to do is read my mail and get on with life. =8^) I don't want to program my mail client; I just want to use it to efficiently do what I need to do, so I can spend more time playing Dragons Age. :) One final perspective: we invented computers to do tedious stuff for us. Application software should ideally be written once, so that people don't need to independently keep implementing the same solutions over and over again. The Unix Philosophy is very good for developing small tools with a relatively small universe of utility; it's not very good for gluing together a very large number of peices, precisely because it requires the user to keep reinventing something that should have been done for them. I support keeping the code simple, but you have to balance that against complexity of use by the user. If something is hard in code, but also hard for the human, you want it in the code, with suitable comments around it to keep people from tampering with it unknowingly. In code, you only need to implement it once; the human will have to do it over and over again. And there are lots of humans. :) -- Derek D. Martinhttp://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. pgpJbhRMY3gBS.pgp Description: PGP signature
Re: Unix Philosophy (was List management headers)
On Fri, Jan 29, 2010 at 12:55:32PM -0600, Derek Martin wrote: Another way to look at it, if you think that the above idea is stretching the Unix Philosophy beyond what was intended (which it very arguably is), is that the Unix philosoply is about 4 decades old, and software (and users) have long since evolved to a point where it just doesn't always make sense. For an application like e-mail, there *is* a lot of functionality that needs covering. You can either write one monolithic application to handle it all in a consistent way, or you can stick with the ancient philosophy and glue all the bits together in a way that, for my money, eventually gets pretty clunky, or at the very least requires a lot of user effort to get it all working. The small pieces each have their own interface, which often doesn't play well with other peices without some coercing, unless they were designed from the beginning to work together. It sounds to me like you may be confusing two ideas. One idea is a way of assembling an application from small programs that perform discrete tasks in a script or pipeline. The other idea is a user's experience that an application came with some assembly required. There is not any reason that an application that is sophisticated and complete cannot be assembled from small parts. You can distribute a sophisticated and complete application fully assembled, no matter how many pieces form it. The advantage that assembling an application in the UNIX-y way has over a monolithic application is that the parts can usually be disassembled and reassembled for the purposes of testing, automation, creating new and improving old applications. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: Unix Philosophy (was List management headers)
On Fri, Jan 29, 2010 at 12:55:32PM -0600, Derek Martin wrote: There are a couple of ways to look at this. One is this: the Unix philosophy is to do one thing, and do it well. In the case of my mail program, the one thing is to handle my mail. It should be capable to do all of the essential things that involve handling mail, all of the common things, and most of the less common things. For the rest, ideally it should have nice hooks to make it possible (if not easy). Of course, this encompasses a great deal of functionality. You can implement all of it, and arguably still hold true to the Unix Philosophy. No, if you study the design of unix programs closely you will see that the The Unix Philosophy is Make a program as simple as possible, and then make it a little simpler than that. I support keeping the code simple, but you have to balance that against complexity of use by the user. Exactly.
Re: Unix Philosophy (was List management headers)
On Fri, Jan 29, 2010 at 01:40:18PM -0600, David Young wrote: It sounds to me like you may be confusing two ideas. One idea is a way of assembling an application from small programs that perform discrete tasks in a script or pipeline. The other idea is a user's experience that an application came with some assembly required. *I'm* not confusing anything with anything. :-) What I was doing, however, was attempting to address (what I think are) David's concerns about some arguments that tend to crop up against adding features in the name of the Unix Philosophy. There has been a tendency in some quarters to blindly and rigidly advocate that following the Unix Philosophy is the One True Way, which has often hindered progress. There is not any reason that an application that is sophisticated and complete cannot be assembled from small parts. True... but, there might be usability reasons why it *shouldn't*. That's sort of what I'm trying to say [although my main point, which I may not have made well, is that using the Unix Philosophy as justification to not implement a beneficial feature in mutt is mostly kind of lame]. In potentially a lot of ways, it's just easier for users to deal with monolithic apps. Especially if you yourself need to actually assemble the smaller programs into a pipeline (every time you need to use them), but even if you don't. You can distribute a sophisticated and complete application fully assembled, no matter how many pieces form it. Indeed you can... qmail comes to mind, but IMO qmail is a tangled mess to manage, an example that makes my point above. The code is elegant enough, but the flow of mail through the system is complex, which can make for some difficult troubleshooting. As I said, I believe that if you need to have complexity, it should be in the code, not on the user end. Often on mutt-dev there are arguments against developing particular functionality (like, oh, I don't know... SMTP capabilities) because there's something else out there that does it, and you should just glue that onto mutt instead. Usually such features were almost automatically labeled bloat. I see instead added user complexity. Instead of one app to install, configure, and maintain, you now have two (or 12) -- each with their own quirks to learn and love. :) Sure, Mutt has SMTP functionality now, but it took about a decade and a couple of changes of maintainers for that to happen. The benefit of adding this functionality seems so obvious; yet it took forever to convince the devs it was a good idea. This is, IMO, a fine example of where a monolithic application wins, and arguing no way, unix philosophy! loses. This, I believe, was what David was referring to, when he commented: I would love to see RFC2369 handling built in to mutt, but have not had time to explore this in code. I'm certain there are others here who would cite the Unix Philosophy or whatever, and assert that an external program could do this as effectively and with cleaner layering. Of course, in this case, Mutt could provide its SMTP functionality in a separate program; as long as that separate program is behind the scenes, and the user doesn't need to do anything special to configure it, then you can have your Unix Philosophy and eat it too. But in the grand scheme of things, there's probably little practical benefit to splitting it off into a separate program, and indeed it was not implemented that way. And it's not always that easy to do; it's generally much easier to communicate the bits that need to be communicated via function call, than it would be to implement some sort of IPC. The advantage that assembling an application in the UNIX-y way has over a monolithic application is that the parts can usually be disassembled and reassembled for the purposes of testing, automation, creating new and improving old applications. Absolutely. The advantage of a monolithic app is that, in cases where one is called for, most users usually won't care about those issues, and there's usually a lot less for them to worry about / manage with a monolithic app than with a bunch of smaller programs. -- Derek D. Martinhttp://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. pgpjNb68s5z1z.pgp Description: PGP signature
List management headers
Many mailing lists tuck links and addresses useful for list management in the headers, like List-Unsubscribe and List-Help. I looked around in the manual and in Google, but I couldn't find much. I'm assuming this means mutt commands based on the info in these headers don't exist. Am I correct here? It would be nice to have commands available to display those urls in the headers, or send an email to List-Help or List-Unsubscribe.
Re: List management headers
On Tue, Jan 26, 2010 at 12:22:08PM -0500, Tim Gray wrote: Many mailing lists tuck links and addresses useful for list management in the headers, like List-Unsubscribe and List-Help. I looked around in the manual and in Google, but I couldn't find much. I'm assuming this means mutt commands based on the info in these headers don't exist. Am I correct here? It would be nice to have commands available to display those urls in the headers, or send an email to List-Help or List-Unsubscribe. If you look at the headers you'll find direct instructions for these lists? Steve -- NetTek Ltd UK mob +44 7775 755503 UK +44 20 7993 2612 / US +1 310 857 7715 / Fax +44 20 7483 2455 Skype/GoogleTalk/AIM/Gizmo/.Mac/Twitter/FriendFeed stevekennedyuk Euro Tech News Blog http://eurotechnews.blogspot.com MSN st...@gbnet.net
Re: List management headers
On Tue 26, Jan'10 at 5:23 PM +, Steve Kennedy wrote: If you look at the headers you'll find direct instructions for these lists? Yeah. It would be nice if you didn't have to weed through 3 screens of headers to find the right link. Like a 'list details' command that extracted the appropriate links/emails from the headers and let you open the right links or send a mail to the right address. I've seen it in some client in the past. I don't recall if it was in mutt, pine, or some GUI client (probably Mailsmith if any of the ones I've used).
Re: List management headers
On Tuesday, 26 January 2010, 12:30:17 -0500, Tim Gray lists+m...@protozoic.com wrote : Yeah. It would be nice if you didn't have to weed through 3 screens of headers to find the right link. Not exactly what you're looking for, but unignore might help.
Re: List management headers
* On 26 Jan 2010, Tim Gray wrote: Yeah. It would be nice if you didn't have to weed through 3 screens of headers to find the right link. Like a 'list details' command that extracted the appropriate links/emails from the headers and let you open the right links or send a mail to the right address. I would love to see RFC2369 handling built in to mutt, but have not had time to explore this in code. I'm certain there are others here who would cite the Unix Philosophy or whatever, and assert that an external program could do this as effectively and with cleaner layering. In any case that solution is perhaps more approachable for someone with time to look into the problem. Such a program might work like urlview: parse out List-* headers from a piped-in message and display a menu of options that these headers present (and then generate and submit mail messages as appropriate). -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: List management headers
On Tue 26, Jan'10 at 12:09 PM -0600, David Champion wrote: Such a program might work like urlview: parse out List-* headers from a piped-in message and display a menu of options that these headers present (and then generate and submit mail messages as appropriate). I guess that would work alright. Generating an email directly in mutt would obviously be a smoother user experience, but it would make for an interesting little python script or something.
