Re: NSE structured output--normal output formatting

[David Fifield <david () bamsoftware com>]

On Fri, Jul 20, 2012 at 10:39:21AM -0400, Patrick Donnelly wrote:
> On Thu, Jul 19, 2012 at 6:49 PM, David Fifield <david () bamsoftware com> wrote:
> > We have discussed how scripts should be able to return a table with nice
> > structured semantic fields, and also the need to provide less robotic
> > output for humans reading -oN.
> >
> > We've discussed some possible options for producing normal output. These
> > include
> > * requiring the script to give to NSE a function that converts its
> >   output table to a string,
> > * requiring the script to annotate its returned table with metadata that
> >   describe how the table should be converted to a string, and
> > * returning a string along with the table.
> >
> > I want to strongly suggest that we adopt the technique of just returning
> > string alongside the table.
>
> I think ScriptOutput tables (objects) would be the "future", having a
> __tostring metamethod or some method for changing the table to a
> string for normal output. I don't see the value in having scripts
> continue to make a string version of their output alongside the table
> version.

This doesn't make sense to me. If the script can provide a function that
converts its output to a string, it can also call that very same
function to produce a string. (That's all NSE is going to do, anyway.)

More importantly, the two models do not only differ in who gets to call
the function. A formatting callback or metamethod is strictly less
flexible. It would require rewrites of many existing scripts that build
up their string output incrementally while running.

Further, I see a formatting callback as requiring hundreds of lines of
new code, not dozens, and being harder to explain to script developers,
especially if hidden in a metamethod.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/