Paul Vixie writes: > > On 2012-06-26 2:28 AM, Jon Steinhart wrote: > > Paul Vixie writes: > > > >> let's start talking about what it should look like? > > Well, for starters, it shouldn't include any threatening commmentary! > > Big thing that I think that it needs other than cleanup is the ability > > to scan for attachment part headers instead of stopping at the end of > > regular headers. > > well that didn't take long. :-). > > m_getfld() is the heart of MH. everything about the storage and access > model is contained in it, either by its signature or its logic. i'm > opposed to grafting MIME onto it with a couple more arguments that if > non-NULL will trigger additional behaviour. > > so when i say "let's talk about what m_getfld should look like" i really > mean "let's talk about what MH's storage and access model should be." > > int > m_getfld (int state, unsigned char *name, unsigned char *buf, > int bufsz, FILE *iob) > > your move. > > paul
OK, well, I understand your point of view here but I really don't think that my point of view is really different. As far as I can tell (once I get past the dire warnings), the m_getfld looks for stuff in a mail message and stops once it gets what it needs. It was designed in the age before MIME, so its notion of what constituted headers was limited. Now, MIME did many things that maybe should have been kept separate in hindsight, but one of them was to extend the definition of headers. So, I'm proposing that m_getfld be extended so that it finds these "extended" headers. I'm not presently suggesting that it be extended to be able to decode the multiple body parts that MIME squeezes into the old definition of body. As I said in an email years ago, I'd be happy to be able to have scan optionally do something like this: 1695+ 06/26 Paul Vixie Re: [Nmh-workers] mime-aware filtering?<<On 1695.1 image/png name="foo" 1695.2 application/pdf It would be nice to be able to decode the body parts to flesh out the part subject lines but even without that it would be a huge improvement. I realize that this could all be done by hacking a script around mhlist but that is really ugly. Biggest internal structural change that I can think of is that we might want some array of fields indexed by part number, or a tree of fields. Jon _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
