delimited fields

[Carter Bullard]

They don't have to be linked in any way, and
if we all have the impression that its an exceptional
output format, then it doesn't need to be designed for
machines in any way.

So what do we want to do?  If its make the traditional
output easily to read by humans, then the space between
the ports makes some sense.

For when the RA_FIELD_DELIMITER is in play, I can put
in an empty field for the port where necessary.  Would
that work?

Carter


-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Russell Fulton
Sent: Tuesday, October 24, 2000 5:23 PM
To: argus at lists.andrew.cmu.edu
Subject: Re: RE: RE: delimited fields



On Tue, 24 Oct 2000 17:09:44 -0400 Carter Bullard <carter at qosient.com> 
wrote:

> Hey Russell,
>    So, right now, when we print out the unreachable port
> numbers (using the -R option (response data)) you'll
> still see the same column number.  We print the two
> text fields in the Src and Dst Byte fields.
> 
>    Frag reports still need to be implemented but they
> were going to also have the same number of columns of
> whatever.
> 
>    So with the FIELD_DELIMITER support we can do what
> you suggest, however the default "pretty" output,
> will end up with unbalanced output.  Do we want to
> consider the "pretty" output as an exception?
> 

I assumeby pretty you mean the traditional ra output we know and love 
;-) Since this is designed to be read by humans it is important to keep 
it easy to interpet and 'pretty'.  If I was forced to choose between 
ease of handling delimited output for machine and ease of interpreting 
human output I would opt for maintaining the human output every time.  
After all cpu cycles are cheap and use perl hackers can cope with 
anything ;-)

One thing I don't quite understand is why the two formats should be 
linked.  Anyway this certainly isnt a big deal as far as I am 
concerned.  The current state is a great improvement on the 1.8.1 
format from the programming point of view.

Cheers, Russell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20001024/257864ca/attachment.html>