Re: [Nmh-workers] iCalendar support

[Ken Hornstein]

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

Well, we haven't really nailed down what exactly a "module" is.  There
was that post I did a while ago where I suggested a concept called "modules"
here:

   http://lists.nongnu.org/archive/html/nmh-workers/2014-07/msg00058.html

I'm not saying that we have to follow that concept.  But the thing that sticks
out at me is that every new "module" in this implementation requires a source
code change.  That's what seems wrong.  If some kind of new content shows up
that we want to process and incorporate in a reply message, it shouldn't
require changes to repl.

Okay, you're going to (fairly) point out this makes things harder.  I can't
disagree with that.  It's just ... we're starting to now grapple with
some truely hard problems, like how exactly a MIME reply is supposed to
work.  This is something a lot of MUAs don't deal with very well.  I think
we owe it to ourselves to try to get it right.

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

Yeah, that's what I was trying to get at.  I'm not sure of the right
thing to do here either.  We might need a new header with some special
syntax that mhbuild knows about.

--Ken