[2010-12-01 07:43] Jon Steinhart <[email protected]> > > Sorry, seems like my comments offended you. nmh is a community project. To > me > that means that anybody can propose things but those things are subject to > review > by the larger community. The result usually turns out to be better. This > doesn't > mean that your efforts aren't appreciated. It helps to have a thick skin; > it's > easy to get offended when people you've never met make comments.
Thanks. Yes, the thick skin is something I often lack. > Maybe I don't understand your proposed changes. Apologies if I get this > wrong; > I didn't save a copy of your original email and the archives are currently > down. > > There are currently -attach options on send and whatnow to support the > non-standard > attachment header. I don't even think about this because my .mh_profile > includes: > > send: -alias aliases -attach X-MH-Attachment > whatnow: -attach X-MH-Attachment > > My understanding is that your change would be to remove the -attach options > and to > have the .mh_profile include something like this instead: > > attach: X-MH_Attachment That's only the minor change I made (in order to enable any program to take part without the need to add the -attach switch to all of them). I did it because it reduces overall complexity and simplifies the configuration (which currently is very complex; you can hardly use nmh without spending weeks in setting everything up once). This change, AFAIS, only breaks with the versions since you added your attachment system and only in the way that the -attach switch is not recognized. One hardly wants to define some non-standard attachment header anyways, therefore my version adds a default one. The attachment format needs to be specified differently if one likes to change it. Where compatibility does get broken is that my attachment system would always be active, while your's by default would not. But that's the crucial point! As I said above, currently nmh can hardly be used (for modern emailing, that people probably like to do) with the default setup. Everyone of us, of course has his rather complex setup which does what he likes, so you don't see this problem anymore. I needed about two month until nmh had been well configured. This included Jerry Peek's book or course, the man pages and the pretty old FAQ. I needed lots of time to figure out all the stuff. You often don't know if it is broken or if you just haven't found out where you need to configure what. Hence I would like to see nmh do the most likely thing per default. This for instance includes converting foreign charsets to the native one on show. This also includes the definition of the attachment header. I asked myself why a user or system administrator should need to set it manually. I fould no answer besides some corner cases where the behavior would change. If no such header is present and all text is ASCII then the behavior is the original. If a header is present or non-ASCII is used then the message is MIMEified. This very likely is what is intended. For sending non-ASCII text without MIME I don't know. My patch MIMEifies in any case if it's non-ASCII. Therefore my patch removes the need to run `mime' at the whatnow prompt. Why does the user need to decide if he needs MIME or not? Mostly he does not know an will MIMEify always. Then plain ASCII messages are MIMEified too which is not necessary. My patch does the more reasonable thing. Further more it does not require the user to know about mhbuild(1) directives and makes /^#/ non-special (that's what your system provided). Running mime at the whatnow prompt to early had been a pain too as one was not able to modify the draft later one. It also removes the problems that can occure when mixing automimeproc:1, /^#/-lines, and your attachment system. In fact, instead of having two attachment systems, we only have one. It includes MIME forwarding too, which seems to be only too logical. Of course there still are problems which need to be solved. The two mayor ones are: (1) Less flexibility there are MIME structures that are not possible to create. We should carely evaluate which ones are really needed and how to access the full flexibiliy of mhbuild with the proposed system. (2) MIME type guessing is very dumb. I'd like to see a system here that works out-of-the-box, in order to avoid heavy configuration on setup. Adding douzends of mhshow-suffix- lines in the profile appears merely as a workaround. GNU file(1) provides -i which provides the information needed, but this is not portable (actually SUSv3 requires -i to mean something else). > Here are my unfiltered thoughts on this; maybe seeing them you can craft a > more > compelling rationale for your proposed change: > > 1. It doesn't fix anything because the current mechanism isn't broken. It's not broken but it is still clumpsy from the user's perspective. > 2. It doesn't simplify anything from a user perspective. Yes it does. See above. > 3. It just looks like a "semantic sugar" sort of change. No it's a general simplification. > 4. It breaks things for existing users. It may, yes. But (naturally assumed that we talk about the concept, not the work-in-progress implementation) it breaks only corner-cases while simplifying things in the common cases. > 5. Does he know that options can go into the .mh_profile? I do. But tell me, how bulky is your profile and the one of others. Do we want to require users to write such a profile before being able to use nmh in a common & modern way. Also, do we like to add more and more options to the programs for every feature we add? > 6. I don't see any pros to outweigh the con of breaking things. I hope that I convinced you of the opposite. :-) > I would suggest that if there is a compelling reason for your change that you > could > do it without removing the old code. That way your new mechanism would work > without > breaking anything. This is something where we can talk. Removing -attach is not the main point of my patch. Although, I don't like to carry everything with us that oneone once added to nmh. > I know people who have crafted their own custom environments around the > current > mechanism and an upgrade script is unlikely to catch them. nmh has a small > but > dedicated user community and breaking things upsets them. If it has a small and dedicated user community, then a change that improves nmh will likely outweight five minutes to check/change one's configuration, won't it? > Finally, I think that the goal is to keep improving nmh which to me means > cleaning up > the codebase, fixing bugs, and adding new features. Your proposed change > doesn't appear > to do any of these unless I'm missing something. My change improves the usage of nmh. Like your attachment system did. See it as an improvement to your attachment system, or as the concept of your attachment system applied to a wider range. It simplifies a conceptual approach. Maybe we can identify further places where this concept proves good. Encrypting and signing comes to mind, which could use this concept too, perhaps. I hope that I explained the patch and my thoughts behind it well enough now. You probably haven't had a deep enough thought on it. Please engage into the approach and thing about it. I really believe it is worthwhile -- the approach, not the implementation. meillo _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
