[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Nmh-workers] vague, undefined thoughts on nmh MIME processing,
Ken Hornstein <=