kre wrote:
Date: Wed, 12 Nov 2014 13:14:55 -0500
From: David Levine <levinedl(_at_)acm(_dot_)org>
Message-ID: <5112-1415816095.139185@v4jZ.SrI8.S3lW>
| 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers