nmh-workers
[Top][All Lists]
Advanced

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

[Nmh-workers] vague, undefined thoughts on nmh MIME processing


From: Ken Hornstein
Subject: [Nmh-workers] vague, undefined thoughts on nmh MIME processing
Date: Wed, 16 Jul 2014 00:30:13 -0400

So, here are some thoughts I've had about rearchitecturing the nmh MIME
handling, now that I've been more in the guts of it for 1.6.

I was thinking we should have different types of ... let's call them
"modules" inside of nmh.  Roughly, in order, they would be:

- Parsing.  This would take a message as input and generate a MIME content
  structure as output.  By default it would only parse message headers;
  it would start processing more parts if requested by higher-level APIs.
  This would allow us to avoid reading message bodies for things like
  scan and pick.  You couldn't supply your own parsing module; you'd have
  only use the one we supply.

- Selection.  This would take a MIME content structure as input and
  select which parts would be passed to the next module.  By default all
  MIME parts would be passed on, but (for example) show could default to
  content-type == text && inline.  This is where you'd implement things
  like the -part and -type switches to mhshow.  Maybe you could supply
  your own script/rule here; for example, you might want to play audio/wav
  files if the %{from} matches your VOIP provider, but not anyone else,
  to use a recent example.

- Decoding/canonicalization.  This would convert the raw data in the message
  to it's decoded and/or canonical form.  I don't think there's a value in
  supplying your own decoder here; the number of content-transfer-encodings
  is pretty small.

- Transformation (optional).  Some content-types may cause a change in the
  actual content.  I'm thinking of things like message/rfc822 or the
  encrypted mail content-types.  But should these actually cause a
  transformation and pass that back up to the selection module?  Or should
  they be treated like nested content types like multipart?  Still thinking
  about this.  Obviously this would be ripe for external programs to do things
  like message decryption.

- Conversion (optional).  If the content is a certain type, it may
  require a conversion before it can be passed to the next module.
  This could be character set conversion for text types, or converting
  text/html to something palatable for a tty.  I'm not sure if we want two
  steps here; some content the character set should be handled by the
  conversion program (text/html) and some it should be handled by us
  (text/plain).  Still thinking.  You'd probably handle external
  content types here ... or maybe this belongs in Decoding?  Not sure.

- Output.  This could write to stdout on a tty, or to a file where the filename
  came from a Content-Disposition header.

Most programs would string together all modules; I think the big difference
is between output modules.  Again, these are vague thoughts based on what
I've seen on nmh internals and operations that would be useful.  Comments
are welcome!

--Ken



reply via email to

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