It seems that taps for ethereal or tethereal need to be coded virtually
independently, and that concerns me. At one point (about 1.5 weeks ago) I made
an attempt to try and correct this, but discovered it took more time than I had
available that evening :)
My general idea is this, it would be very nice if text output was the *norm* for
most taps. I would hope that there would not need to be gtk/gtk2/(insert other
random gui here) versions of each and every tap that anybody plans to
implement. I would really love to see taps outputting to a FILE* that they are
handed, and having the tap core handle most other draw related functionality.
Like I believe that for now the general format of output is:
===============================================
Pretty Name for Tap
(something about the filter string used to generate the tap)
(optionally some other header information such as column names)
(body of the data in some kind of table format)
===============================================
The FILE* could direct output to stdout (what is currently done) or to a normal
file (a pure text feature that could work for both ethereal -z and tethereal -z)
or to a *pipe* or other special method for passing data internally without using
the harddrive.
At the very least, a generic gui handler could take text from a pipe and format
it nicely.
I would imagine that it would.
1. skip over the ============
2. create a window with a title of "Pretty Name for Tap" (and optionally the
filter string)
3. create a vbox (for holding labels)
4. for each remaining line of text, create a label, insert the text into the
label, and shove it into the vbox.
A slightly more sophisticated GUI handler might go one step further in doing
something like
1. skip over the =============
2. create a window with the title of "Pretty Name for Tap" (and optionally the
filter string)
3. skip over the extra info (or interpret them in the even smarter case)
4. count how many columns (by possibly looking for 2 or more spaces or a tab
character between columns)
5. create a clist with the proper number of columns and adding column headings
based off of parsing in 4 (or 3)
6. for each row, take data and shove it into the fields of a new row.
Another generic GUI interpreter would interpret explicitly numerical data such
as iostat and plot it.
Another approach would be for a tap draw routine to build a table using some
kind of data structure and then call a display routine (that would be different
depending on if it was linked to ethereal or tethereal)
**********************************
There is also the somewhat distinct concept of taps that have per-packet
information to display. Items such as protocolinfo (and tcp sequence analysis)
and other taps yet to be conceived. It would be interesting if the tap that
generated the info was somewhat removed from the item that actually put the
information in a particular place (ie protocol tree, col_info, etc...)
In some ways it would be nice if a tap could provide per-packet summarization
without being hard-coded for which way the information should be displayed. How
exactly that is handled is another question. It would be interesting if taps
with that functionality had a draw_packet routine or something like that.
Just thoughts... what do others think?
