Jon Steinhart wrote:
>> Yes. m_getfld will give you the body text (in a series of chunks
>> the size of the buffer you hand it, IIRC) and what you do with
>> it after that is up to you. This is how nmh's existing MIME
>> handling code works. (I suppose you could propose replacing
>> m_getfld completely with something with a different and MIME
>> aware API, but that would be an extensive project...)

>Well, yeah, that is what I'm thinking about.  Seems silly to have m_getfld call
>something that sort of looks like m_getfld but is different.  Making it work 
>down
>to all of the body parts would in my mind be architecturally better for nmh.  
>But,
>as you say, more work.

If you did want to replace it I would suggest that a new API
ought to involve just getting a complete header/body part
in one go rather than m_getfld's keep-looping-round-til-I-say-stop
approach. That design made sense on the VAX (it is attempting
to avoid memory allocations) but on a modern machine it
just makes the calling code jump through hoops and liable
to buffer overruns or random fixed length limits.

m_getfld but with some extra states for MIME parts I think
would not be a very useful direction to go in.

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Reply via email to