[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] mhlist output format
From: |
Paul Fox |
Subject: |
Re: [Nmh-workers] mhlist output format |
Date: |
Fri, 18 Apr 2014 13:15:32 -0400 |
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)