first question: am i correct that mhlist is the only way to
dump the property tree of a MIME message?
As a standalone utility ... yes, I believe that's correct. You can get
most of the stuff with varions escapes we have inside of mhshow display
strings.
so: any thoughts on whether this sort of "script readable" output
capability should be added to mhlist? and, if so, what form should the
output take? (xml crossed my mind, but that would make it a lot harder
for "simple" scripts to parse.)
First thoughts ... yes, we should absolutely do something! Second
though: I don't love this. Okay, that's not very helpful, is it?
It just seems .... hm, like it outputs a ton of crap, where you don't
normally need a ton of crap, you need a few small things. Also, I see
some possible issues in that MIME parameters that contain a " in them
may be problematic. Rather than just outputting EVERYTHING, we should
be smarter. I mean, do you care about all MIME parameters? Or only
specific ones, dependending on the content-type?
I am wondering if maybe it would be more useful to make the output
controllable via mh-format; you could make parameters be components
like they are for non-displayed content markers in mhshow. Just thinking
out loud here ... I'm not really sure yet what is the "right" thing to do.
Also, I don't know if mhlist is the right place to put this code; maybe
it should go somewhere else, in some new utility.
Robert Elz has made the case before that it's wrong to embed a lot of
functionality into nmh, but it should be done via external scripts.
I don't agree with this sentinment for everything, but it does make sense
for a number of things. I think we just need to figure out the right
primitives to make this happen.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers