Re: [Nmh-workers] Should attachment header handling be in send?

[Joel Reicher]

Apologies for the length of this message. The proposal at the end is
simple, but I'm finding it difficult to give all my rationale for it.

> > Then why don't you feel the same way about mhbuild? My problem with
> > send handling attachment headers is that it's inconsistent with the use
> > of mhbuild. If MIME were being done from scratch, I might agree with you.
> 
> You seem to be arguing for what you feel is "program consistency"  I'm arguin
> g
> for "good user interface".  It's too bad that mhbuild was written the way tha
> t
> it was, but that doesn't mean that we have to suffer with it forever.

I see your point. I agree that there seems to be a problem with mhbuild.
I'm now trying to understand why it's been done the way it has so that
a better design might suggest itself.

While I've followed the history back to the original introduction of
mhn in 6.8, I can't find anything on the rationale. This part of the
mhbuild man page comes closest, perhaps...

       Finally, you should consider adding this line to your profile:

            lproc: show

       This way, if you decide to list after invoking mime, the command

            What now? list

       will work as you expect.


To me, this suggests that the original idea of building a MIME message
from a composition draft is that the user should be able to preview the
result of MIMEfying. I think this is a good idea.

Two possibilities then present. First is that the output of mhbuild
not be editable in the same sense that the composition draft is. I
don't like this idea, but it might be cleaner. Second is that the
output of mhbuild be treated as the new composition draft, and this is
what currently happens. The problem with this second possibility is, of
course, what to make of running mhbuild on the output of a previous
mhbuild run.

So, do we find a way to make mhbuild smart enough to process its own
output from a previous run? I'm not sure that's possible, or even
a good idea. For instance, even in the special case of an attachment
header, the extra MIMEfying would have to parse the draft it's been
given, establish whether it's a MIME message, if so, add the attachments
such that they use the separator already in the message and perhaps
modify the content-type of the message if required, or something like
that.

If it is OK to treat attachment headers as this kind of special
case, then having the processing in send is probably correct, but it
needs to be smarter. I should be able to use forw -mime, attach a file
at the whatnow prompt, and have everything work. As it stands send will
fail if I tell whatnow to call mhbuild first, or if I don't, the mhbuild
directive gets ignored because the message body is encapsulated by
the attachment header processing.

But even were this special case a good idea, I still don't think
mhbuild should be required to make sense of an apparently already
MIMEfied message. I can't imagine a way to distinguish between an
mhbuild directive and a line beginning with a # in a text/plain part.

I think the simplest possibility of all, however, is that mhbuildish
stuff be done exactly ONCE. So I propose the following:
o If mhbuild is called (manually) on a composition draft that has
  attachment headers, that it do the attachments.
o If a MIMEfied message with attachment headers is given to send, that it
  skip the attachment code.
o If whatnow is asked to attach a file to an already-MIMEfied draft,
  that it refuses.

This is probably best done by splitting out the code that's currently
in sendsbr.c, but the main idea is that mhbuild called explicitly will
do both directives and attachment headers, but that mhbuild called
implicitly by send will not do directives. And mhbuild will only need
to be run once, overall.

Cheers,

        - Joel