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, [email protected] (arlington, ma, where it's 39.6 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
