Re: [Nmh-workers] iCalendar support

[Robert Elz]

    Date:        Wed, 12 Nov 2014 13:14:55 -0500
    From:        David Levine <address@hidden>
    Message-ID:  <address@hidden>

  | It'd be a bit messy to extract the Organizer address and
  | still use a components file for the reply.

No, it isn't ... long long ago (approaching 20 years now) I had
a similar problem to deal with, needing to send many (hundreds a day)
of yes/no replies to a formalised message format (not iCalendar, and
almost no-one else would have ever seen it) - it really is not hard.
(The replies were also  in a fixed format - not because it was really
required in my case, but because they were all machine generated, and
making them all be different would have been hard...)

Further, it requires (or might (perhaps even should) require) no changes
to nmh at all.  It certainly did not in my case.

This is all based around the ability to add new commands (which can be,
and in my case, were, shell scripts) to the MH command set, and the
fact that messages are files, and can be processed by the regular text
processing commands (the messages I was dealing with had no chance of
being base64 or QP encoded, so I didn't need to deal with that - but if
iCalendar messages do, then there are plenty of base64 decoder programs
already around (and nmh could supply, or include, one if that would be
useful) and if there are no QP decoder programs (don't know, never looked)
creating one would be all of a hour's work.

All that matters to make this easy is that the request being processed is
in a reasonably restricted format (which I suspect iCalendar messages are).

All that MH needs to be able to do, if it can't already (and I suspect it
probably can) is to extract a MIME part of a message (well, clearly mhstore
can do that) ideally selected by MIME type rather than number (not sure of
that part, but it should be easy to add) and then write a script to
see if the message is a multipart, if so, extract the iCalendar part, otherwise
just take the entire message, decode it if a header indicates that it is
base64 of QP, pass it to your favorite test processing tool (like sed) to
extract the information from the request that is needed to process it,
(probably) take a yes/no from either the name of the script, or an option
given to it, build a reply components file (all filled in) and then pass that
off to "send" to actually send the reply.

The ability of mhstore to extract a part (or parts) to stdout rather than
a file (if it doesn't exist already) would be about the most useful
addition (if an addition is needed) so that the icalendar part could be
just piped into the text processing tool (makes it easier to avoid
leaving trash around if the process is interrupted, or the system crashes,
or whatever).

There is absolutely no need to go complicating repl for this kind of thing,
if there's a need to add user generated text to the formatter reply, then
instead of just invoking send directly, the constructed iCalendar reply can
be handed to comp -form instead.

If you want to annotate the message being processed, the script just
runs anno - it can also add calendar requests to a magic sequence if
you like (mark) remove them from unseen if that's useful, etc.

Further, appropriate use of mhparam and mhpath can allow the script to
appear to be just another mh copmmand (with default options set in the
profile, etc).

I don't think I still have the scripts I used way back then (haven't needed
them for more than 10 years now) but my exmh config still has Accept and
Reject buttons in its per message button bar that used to (would still attempt
to) run those old scripts...   And of course then can (could) be run from the
command line, just like any other mh command.

If it turns out (I am not much concerned with iCalendar myself) that those
messages have a format that is beyond the abilities of sed or awk, then
an icalendar parser program written in yacc shoudl be feasible - ideally
just to parse the file and output a simlified format that sed could process
(so it would be more useful for other applications, and the basic parser
part doesn't need to be re-implemented over and over).

This is the beauty of the MH design - which includes both the separate
commands, and the filestore (to link this in to the other thread...) that
things like this are truly easy to add.

Once done once of course, it would be useful to distribute it via the
contributed software part of nmh, so everyone doesn't need to go roll
their own.

kre