Ethereal-dev: RE: [Ethereal-dev] RFC framework for graphical extensions like t he recent rate_
Rather than use CSV, it might more prudent to use XML as the interface. That way a more structured dump can be produced, and then fairly trivially converted to CSV or input to GNUplot etc.
For what it's worth, I have to say that Gnuplot output is little ugly to my eye. While it would be a good start, and quite portable, I think being able to easily output data to drive a package like say SciGraphica http://scigraphica.sourceforge.net/ would be much nicer. I have also played with the GtkExtra APIs (SciGraphica uses these) and I don't think they would be too difficult to build in as plugins to Ethereal. (They do seem to be fairly CPU intensive compared to Gtk widgets though)
Also Ronnie mentioned that only a one-way would be needed. However,I tend to believe it would be most useful to be able to direct Ethereal to display to appropriate packet of interest. For instance when I wrote my "packet fence" display patch http://www.hinet.net.au/~mvisser/ethereal/, you could zoom in and out on the left hand graph. By clicking on the picture of the packet it would then drive ethereal to "scroll" to the relevant decode. Most graphs are going to be formed from a display filter and will be time or frame dependant. Having the option of two-way conversation capability will be useful.
(I'm not sure if you have ever used Intuit Quicken to produce budget reports. It very nicely allowed you to zoom in and out of pie charts and histograms, and this could lead you to the account entries that drove the graph. I haven't seen the same in any sniffer-type tool, but I think this sort of interface will lead to better "expert" capability)
Martin Visser
Network Consultant - Global Services
COMPAQ, part of the new HP
3 Richardson Place
North Ryde, Sydney NSW 2113, Australia
Phone *: +61-2-9022-1670 Mobile *: +61-411-254-513
Fax 7: +61-2-9022-1800 E-mail * : martin.visserAThp.com
