How about this for a generic reply mechanism?
TYPE = content type/subtype
CONVERTER = external program, and any fixed arguments, to convert
content from request to reply
ARGSTRING = arguments to pass from repl to CONVERTER
FILE = full path of message being replied to
1) Add new switch to repl:
-converterarg TYPE ARGSTRING
The switch needn't be used if ARGSTRING is empty and the
pseudoheader (see 2)) is inserted into the draft.
2) For each switch, repl puts one pseudoheader in the draft of form:
Nmh-mhbuild-TYPE: [ARGSTRING] file://FILE
3) For each pseudoheader in the draft, mhbuild looks in the profile
and mhn.defaults for this corresponding TYPE entry to find the
converter that supports it:
mhbuild-converter-TYPE: CONVERTER
It's a fatal error if no such entry is found for TYPE. An empty
entry, e.g.,
mhbuild-converter-text/html:
excludes parts of that TYPE from the draft. Profile entries
override corresponding mhn.defaults entries, as usual.
4) For each TYPE part in FILE, mhbuild runs CONVERTER ARGSTRING on
the part.
Each part in FILE that has no corresponding TYPE entry in the
profile or mhn.defaults is excluded from the draft; the
user can include them using mhbuild directives as usual.
Example 1, text/calendar:
1) repl switch -converterarg text/calendar '-reply accept'
2) pseudoheader: Nmh-mhbuild-text/calendar: -reply accept file://FILE
3) mhn.defaults entry: mhbuild-converter-text/calendar: | mhical
4) mhbuild filters thru: mhical -reply accept
Example 2, text/html:
1) (no repl switch)
2) pseudoheader: Nmh-mhbuild-text/html: file://FILE
3) mhn.defaults entry: mhbuild-converter-text/html: charset=%{charset}; w3m
-dump ${charset:+-I "$charset"} -O utf-8 -T text/html -cols 70 %F | par
4) mhbuild handles with: w3m -dump ${charset:+-I "$charset"} -O utf-8 -T
text/html -cols 70 FILE | par
Example 3, text/plain:
1) (no repl switch)
2) pseudoheader: Nmh-mhbuild-text/plain: file://FILE
3) mhn.defaults entry: mhbuild-converter-text/plain: charset=%{charset};
iconv -f ${charset:-us-ascii} -t utf-8 %F | par
4) mhbuild handles with: iconv -f ${charset:-us-ascii} -t utf-8 FILE | par
FILE must not contain " file://".
repl inserts Nmh-mhbuild-text/html: and Nmh-mhbuild-text/plain:
pseudoheaders in every draft. The user can prevent insertion of
content parts of either of those types by putting corresponding empty
entries in their profile.
Only the highest precedence alternative with a supported TYPE of a
multipart/alternative is used.
mhn.defaults.sh selects the text/html-to-text/plain converter as it
currently does (first of {w3m, links, elinks}). It includes iconv,
and par or fmt, in the pipeline only if found, and uses cat if the
converter command would otherwise be empty.
forw could support this, too.
This doesn't support different ARGSTRINGs or different converters for
different parts of the same TYPE. That would require associating
parts by part number with the ARGSTRINGs or converters. Instead, that
can be done (currently, without any of the above) with mhbuild
directives, e.g.,
#text/html; charset=utf-8 *8bit | mhstore -noverbose -part 42.7 -outfile -
| w3m -dump -cols 68 -T text/html -O utf-8
Suggestions for a better name than "converter" are welcome. There
already is mhbuild-compose-*, but I'm not sure if this new use should
be distinguished.
There's one more minor issue: some content types require the addition
of parameters to the Content-Type header, such as method=REPLY for
text/calendar. One approach would be for the converter to output a
Content-Type header as its first line, followed by a blank line. So
it would look like a header.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers