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. 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.
pgpjNb68s5z1z.pgp
Description: PGP signature
