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

[Jon Steinhart]

> > > Anyway, I'm worried that it is "send" handling the attachment
> > > headers. There are reasons other than attaching files for building a
> > > MIME message, and mhbuild could be called before send. As far as I can
> > > see, the attachment handling mods fail in this situation.
> > 
> > I don't see anything wrong with "send" doing the work.  It's the only 
> > logical
> > place for it, and in my opinion, is really no different than having it 
> > expand
> > aliases and such.
> 
> 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 arguing
for "good user interface".  It's too bad that mhbuild was written the way that
it was, but that doesn't mean that we have to suffer with it forever.

> > Also, I don't see where the attachment handling mods fail.  They treat 
> > anything
> > in the "body" of the message as part 1 regardless of what it is which makes
> > sense to me.
> 
> Then perhaps the failure is a bug.
> 
> Compose a message with an mhbuild directive in it. The simplest example
> of this which is not just another file attachment is forwarding a message.
> At the whatnow prompt, attach a file and run the message through mhbuild.
> The order doesn't matter. Now send the file.
> 
> When send uses mhbuild to handle the attachment header, mhbuild will
> object to the message headers already being MIME-fied. This also
> demonstrates my more "philosophical" objection that mhbuild is being used
> in two different places.

Ah.  Never tried that, so didn't know.  Feel free to fix mhbuild.

> > > Wouldn't it make more sense if mhbuild was given the job of preprocessing
> > > its own composition drafts if they contain attachment headers? I can't
> > > see the downside to that, and it would fit the new attachment handling
> > > into the existing MIME composition workflow more correctly, I think.
> > 
> > I don't understand this.  I suppose that you could add functionality to
> > mhbuild so that it recognizes attachment headers but am not sure why you'd
> > want to do so.  Why would a user want to have to invoke mhbuild when it can
> > be done automatically?
> 
> Because that's what already happens. As I said earlier, it's a matter of
> consistency. automimeproc is the mechanism that exists to invoke mhbuild
> automatically.

No, "automimeproc" doesn't do it.  The problem with automimeproc is that it
invokes mhbuild on EVERY message, not just those with attachments.  That means
that you have to be careful about what you write in EVERY message, making
sure to double all # characters.  Not a good user interface in my opinion.

Again, feel free to fix mhbuild so that it will properly encapsulate already
mimed content.  I don't have the motivation to do that myself.

Jon