Re: [Nmh-workers] iCalendar support

[David Levine]

kre wrote:

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

If we want to handle MIME better, there will have to be changes
to nmh.  That's the ultimate goal here.  repl, especially, needs
help.

As far as being "hard", no, hardly any of this is.  As Ken noted,
figuring out a general approach that will let us support other
MIME types is hard.  That's why we're having these discussions.

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

Rather than reinventing the wheel every time, we should use
what's already in nmh.  It already has base64 and q-p decoders
(and two base64 encoders!).

> 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

It can.

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

Right.  Now, should each of do this and maintain n versions?
Or should we do it once and bake it into the distribution?

> The ability of mhstore to extract a part (or parts) to stdout rather than
> a file (if it doesn't exist already)

It does.

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

I posted an mhbuild directive that does exactly that.  It'll
work for those who want to go that route.

> There is absolutely no need to go complicating repl for this kind of thing,

I don't think any of us will argue that repl works well with
MIME messages.  If complicating it helps, I don't mind.
And "complicating" is a stretch here, I think.

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

Yup, working on it.  The output will be controlled by MH format
so it can be whatever anyone wants (as long at it's supported by
the format engine, of course).

It's almost trivial in yacc/flex but not quite:  there's
context sensitivity, so, e.g., DTSTART might or might not be
the start date-time of the event.

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

Instead of each of us adding it, one of us should if it's
generally useful.

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

That's the point, almost.  Experience to date has been that
contrib doesn't work well.  Furthermore, if it's in the main
code base, it's exercised by more than one user, documented,
tested, and maintained.

David