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