>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
