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.
OK. You raise an interesting point here, but I still think that there are
better ways to address it.
I want to point out that the reason that I did it the way that I did was
because the attachment header is NON STANDARD. I wanted to make sure that
I didn't break anything.
I didn't have your issues in setting up nmh. It worked out of the box.
It was way easier than competing mail systems and easier than most gui
systems. The thing that took time was setting up all of the mhshow stuff
for each mime type.
So two suggestions:
1. Add the -attach options for send and whatnow in the default profile
created by install-mh. Keeps casual users from having to deal with
it and doesn't break anything.
2. Create a program a la configure that scans a target system for programs
that handle content and build the mhshow stuff automatically. This
can't be hardwired because different things are available on different
target systems.
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).
I'm confused here. My attachment code does all of this stuff automatically.
It guesses the content types, eliminates the need to know about mhbuild,
and eliminates the need to run mime. The only problem of which I'm aware is
order-of-operation stuff when wanting to add attachments to a reply to or
forward of a mime message in which you want the original message included.
What am I missing?
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers