[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] iCalendar support

From: David Levine
Subject: Re: [Nmh-workers] iCalendar support
Date: Sun, 16 Nov 2014 22:15:19 -0500

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.,


   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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]