it's a shame to have to foist the decision as to which to use (Attach
or Inline) onto the user.
Well, at a fundamental level we pretty much have to foist that decision
to the user, right? Unless we hardcode a list of types.
perhaps a list of types which should be
inlined by default would be better.
mhbuild --inlined-type text/calendar --inlined-type message/rfc822 ...
(or maybe comma-separated)
Well, other than making the command line super-huge this would work,
but I'm not a big fan personally. I guess my thinking is that
"Attach" is short for "attachment", which is named because of the
Content-Disposition header. We now have a demonstrated need for
attachments which are Not Really Attachments in the proper sense ...
they are inline. We could have people use mhbuild directives, but let's
face it ... those suck.
Someone else brought up the fact that they were unhappy that patches
attached with the Attach header were marked with a disposition of
"attachment" ... which to me again suggests that we need something better.
I think defining it by content-types isn't so great, because really
it seems like more of an issue when dealing with certain MUAs, which
suggests to me you want to change it on a per-message or destination basis.
In terms of implementation ... it should be pretty easy. The magic happens
in build_mime() and setup_attach_content() in mhbuildsbr.c. Seems like
the easiest thing to do is add a flag to "struct attach_list" to indicate
if this attachment is inline or not, and make setup_attach_content()
take that flag and DTRT.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers