Re: [Nmh-workers] mhlist output format

[Paul Fox]

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, address@hidden (arlington, ma, where it's 39.6 degrees)