[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Editing MIMEd messages, etc.
From: |
Joel Reicher |
Subject: |
Re: [Nmh-workers] Editing MIMEd messages, etc. |
Date: |
Fri, 03 Feb 2006 17:12:08 +1100 |
> > > 1. Add an -attach option to mhbuild that is similar to the one that I
> > > added to whatnow and send. If set, mhbuild will process attachment
> > > headers in addition to the mime-composition file body. This is a
> > > bit tricky because the whatnow attach code treats the message body as
> > > a normal file, but should work because the user will either be
> > > invoking whatnow mime or automimeproc which will mhbuild the message
> > > before it gets to the send attach code.
> >
> > Great. That takes care of send invoking mhbuild again because the
> > attachment headers would disappear. I'll do this ASAP and reuse the
> > existing attachment header code. Will split it out into another file
> > for that, I think.
> >
> > Alternatively mhbuild could do the attachment header handling for send too,
> > and instead send could protect #-beginning lines in any draft it gets.
> > Does anyone think that's better?
>
> Well, mhbuild DOES do the attachment header handing for send.
>
> This is a bit tricky. I would say that if mhbuild is being run from send
> then it should do what the current attachment code does which is to protect
> the #s. But, if it is run using whatnow mime then it should not protect
> them because it will make it useless. Possibly the thing to do is to have
> yet another option to mhbuild that indicates whether or not to process
> directives in the body.
>
> If you do this, then mhbuild may need to so some of the automatic filling
> in of things like content-type that the current attachment code now does.
> Again, probably an excuse to go option crazy on mhbuild.
Not quite what I meant. I certainly don't want to add another option
to mhbuild. It's unnecessary. The two possibilities are as follows:
1) Put turn-header-into-mhbuild-directive code in a place that both
send and mhbuild can use. End of story.
2) Put turn-header-into-mhbuild-directive code into *just* mhbuild, and
have send preprocess #-beginning lines to protect them if it has
detected any mhbuild-causing headers, i.e. it's about to hand the
message over to mhbuild.
It's purely an implementation question.
> I have no objection to the new profile components, but would keep the old
> options for compatibility. A question though - would you be able to
> override these components on the command line? I feel that it's good to
> be able to do so, which is why I went with the turn on/of option pairs
> when I did the original code.
Yes, I said I wanted these components to be overridable. To be honest
I hadn't considered a -noattach option but perhaps it's needed for
the semantics I'd intended.
Cheers,
- Joel
- Re: [Nmh-workers] Should attachment header handling be in send?, (continued)
- Re: [Nmh-workers] Should attachment header handling be in send?, Scott Schwartz, 2006/02/01
- Re: [Nmh-workers] Should attachment header handling be in send?, Joel Reicher, 2006/02/01
- [Nmh-workers] Editing MIMEd messages, Jerry Peek, 2006/02/02
- Re: [Nmh-workers] Editing MIMEd messages, Jon Steinhart, 2006/02/02
- Re: [Nmh-workers] Editing MIMEd messages, Joel Reicher, 2006/02/02
- Re: [Nmh-workers] Editing MIMEd messages, etc., Jon Steinhart, 2006/02/02
- Re: [Nmh-workers] Editing MIMEd messages, etc.,
Joel Reicher <=
- [Nmh-workers] Re: Editing MIMEd messages, Bill Wohler, 2006/02/04
- [Nmh-workers] Re: Editing MIMEd messages, Bill Wohler, 2006/02/04