[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] New mhbuild directives

From: Lyndon Nerenberg
Subject: [Nmh-workers] New mhbuild directives
Date: Wed, 14 May 2014 13:01:39 -0700 (PDT)
User-agent: Alpine 2.00 (OSX 1167 2008-08-23)

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.

So now the user has to memorize an internal-to-the-source-code table to know when she has to override the built-in inline/attach defaults? That's just nuts.

However, the mhbuild process could certainly be simplified. The existing syntax is powerful, but something of a pain to use. Having to know the MIME content type for an attachment is burdensome, not to mention a likely source of errors. This problem could be addressed with a new pair of directives:

  #attach ;attribute <id> (comment) [description] filename


  #inline ;attribute <id> (comment) [description] filename

These differ from the existing #type/sub-type in two ways:

1) They automatically determine the MIME type and encoding, and
2) They set the content-disposition as per their directive name.

Both directives fail if they cannot unambiguously determine any required MIME content type-related parameters. I.e., no guessing about character sets for 8bit text in the presence of the C locale. The syntax allows the user to provide MIME attribute overrides, so a C locale user could inline an iso-latin1 document by saying:

  #include ;charset=iso-8859-1 intltext

To ensure correctness, I would want to implement this using an internal implementation of a MIME content-type identifier. I would restrict it to a subset of common MIME types, using a conservative set of encoding defaults. The intent is to get the common cases right, not to get everything sometimes right. There are a couple of light-weight MIME content tasters with amenable licenses we could import.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]