[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

From: markus schnalke
Subject: Re: [Nmh-workers] Understanding nmh (aka. What's the goal)
Date: Thu, 02 Dec 2010 17:01:01 +0100
User-agent: nmh 1.3

[2010-12-01 07:43] Jon Steinhart <address@hidden>
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]