Re: [Nmh-workers] nmh internals: full MIME integration

[Ken Hornstein]

>If we're having lazy evaluation of MIME parts, which is good, can it
>also cover the headers?  `pick --list-id <address@hidden>' isn't concerned
>with decoding Subject and all those Received headers.  It may not sound
>like much, but we have folders with tens of thousands of emails.
>get_header() could note minimal details of each header it comes across
>whilst searching for the List-ID but not bother too much about their
>contents.

I wasn't actually thinking of decoding the headers for things like MIME
content, at least upon read (I assume you're talking about RFC 2047
encoding; personally I doubt you'd notice it on a modern machine, but
I understand where you're coming from).  I was thinking of using an
accessor function to take care of that.

>Also, http://www.ietf.org/rfc/rfc2919.txt says only one List-ID per
>email;  does nmh have knowledge of one-off headers so it can stop
>reading headers on the first match?  That pick uses the `--' as pick
>doesn't know of List-ID, unlike, say, Subject;  perhaps it needs to know
>of more official headers so it can make use of one-off-ness.

Nmh does _not_ know about those things; I'm sort of torn about that.
Right now most tools will combine headers like that into one super-long
header, but the handling is not uniform.  Seems like maybe things like
that should be handled by the accessor function; we can give you the
choice of combining headers, or getting first match.  Something to think
about!

>Whilst looking at pick's source, I found MHPDEBUG;  I don't think it's
>documented but could be useful for those learning pick?  Perhaps it
>should be -debug instead?

I'm with David on this; yes, it should be -debug and documented.

>Also-also, access to raw and decoded headers would be nice, e.g. I
>sometimes want to find Subjects that have `=?utf-8?' in them.

Okay, I guess I could see that.  The normal case would be to decode the
contents completely 

>That's the kind of overhead that would be nice to see done only on
>demand.

I'm still skeptical that you'd even notice (it isn't 1988 anymore!),
but I think if the API was well designed it should be easy to implement.

--Ken