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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers