ken wrote:
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
yes, i think i said that. the quotes need to go away, and parameter
values need to be cleanly delimited some other way -- perhaps by appearing
on lines by themselves. not sure.
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?
leaving aside the debug output i quoted, the output represents exactly
what came with the message. i'm not sure what one would leave out
from that. being destined for a script, and not human consumption,
i'd say that everything is interesting. after all, we're not talking
about that much data -- it's the tree structure of an email message,
not wikipedia. my example message did have a fair amount of
cruft, which is why i chose it. most messages are much simpler.
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.
while i'm sure mh-format could do that, frankly, i'd rather spend my
time programming in shell than writing overly complex mh-format forms.
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.
agreed. i'm thinking of this mhlist change (and i think it should be
mhlist) as supplying a primitive.
paul
----------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 39.6 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers