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

[Ken Hornstein]

>> Okay, I guess I could see that.  The normal case would be to decode
>> the contents completely
>
>Yep, to UTF-8 single lines?

Well, to whatever the local character set is.

>Well, you might be thinking the 2047-decoding might not make a lot of
>difference, whereas I'm thinking a block can be read into a page-aligned
>buffer that has an \n beyond it as a sentinel, then check for
>/foo[ \t]*:/i, ignore any non-foo headers, hunt for the next \n and repeat
>if it's not the sentinel, else read another block and try again.  Stop
>if no more blocks or \n\n.  The detail's a bit more complex but there's
>no allocation and copying for headers seen along the way;  they'll be
>found when they're looked for in turn.  The file's blocks aren't being
>modified so no copy-on-write's occurring.

Sigh.  I wasn't actually thinking of special-casing pick.  If pick wants
a particular header, it can search through Content->c_first_hf for it.
We can put a hash table or some other indexing in there if you want it.
But my mental plan was that there was always going to be allocations.
If pick gets noticably slower then we can revisit this idea.

(As an aside, I see that pick does use ^foo[ \t]*: to match on a header,
but my reading of RFC 5322 is that spaces are not allowed between the
header name and the colon ... but I guess the old syntax did?)

--Ken