Re: [Nmh-workers] iCalendar support

[David Levine]

Ken wrote:

> I was more thinking about preserving MH's historic flexibility.  I guess
> my point was I'd prefer something like this (all are aliases to 'repl')
>
> calaccept: -typearg text/calendar accept
> calreject: -typearg text/calendar reject
>
> Rather than:
>
> calaccept: -calendar accept
> calreject: -calendar reject
>
> Does that make sense?  I don't really like the name 'typearg', I was just
> trying to make the point that I'd like the options to repl be able to be
> used for any MIME type.

I like the idea.  And agree that we need a better name.
This doesn't necessarily have to be tied to MIME types.  For
example, I might want to pass some particular kind of plain
text notification through a special filter for reply.

We'd need to have a convention on how to determine how many
arguments there are.  Fix at two, the type indicator and one
more argument?  Other possiblities (a count at the beginning,
a termination indicator, or constraining the order of switches
and non-switches) are messy.

And it could suggest the form of the pseudoheader, e.g.,

   Nmh-text/calendar: accept; filename

Any back-end nmh program could use what it needs from that.
filename is the full path to the message/file.  It does what
$mhaltmsg now does, but avoids passing data through
environment variables and doesn't rely on whatnow to set
it.  Or to really simplify things, we could grab filename
from the context, assuming that's always set before it's
needed.

David