Re: [Nmh-workers] iCalendar support

[David Levine]

Ken wrote:

> Hrm.  It just seems ... if you want to make that more generic, you'd
> want to be able to pass switches down to the modules that generate
> the reply content.  I'm not sure what that would look like.  Just
> thinking out loud!
>
> Here's an idea.  pick allows --component to refer to an arbitrary
> header.  Maybe use two dashes to indicate a argument to a module?

I'm not opposed, but I do see drawbacks.  If the user has a
good clue to what's available, this works.  In the case of
pick --component, the user sees the components in the
message header and wants to search on them.  But in the case
of repl, forw, etc., the user doesn't know anything about
internal nmh modules.  We could document them, but that
increases the learning curve, and requires remembering (or
looking to see each time) what's available.

Also, -- throws me off.  We could get around that by using
some other syntax, but then I wonder what the point is.
What other modules do we envision?  Is a new switch per
module a problem?

> I'm just thinking of the general case.  In a reply, you
> generally want to "process" the original content somehow
> and incorporate it in your outgoing message.  Okay, fine,
> for things that are traditional "attachments" you mostly
> don't care, but you normally want to take text and prepare
> it for quoting, and now we have a case of wanting to
> process a calendar request and send it in the reply.  I'm
> sure there are other things that would be useful as well.

You know, it would have helped me if you mentioned replyfilter
earlier :-)

> >> So it occurs to me that maybe we should have some
> >> mechanism to allow repl to insert generic headers into
> >> the reply draft that mhbuild could later process.
> >
> >What would it need to do that annotate() doesn't already?
>
> It would use the annotate() function, certainly.  I was
> just more thinking of how to indicate from inside of
> something like mhical that we need to add a special
> header.

mhical doesn't add it, repl does.  But I do see a problem,
and maybe this is what you're getting at:  how does repl
pass parameters to mhbuild?  It's simple for Attach because
it's just the filename.  For iCalendar, there's also
accept/deny/etc., the charset, and maybe the C-T-E.  For
now, anything that fits in an mhbuild directive, but there
could be other things as well.  There are lots of ways to
deal with this:  One pseudoheader per parameter?
"; name=value [...]"?  Serialize the entire struct Content?

David