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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers