>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
