Ethereal-dev: Re: [Ethereal-dev] RFC framework for graphical extensions like t he recent rate_
Hi list.
I hacked together a mockup of the design i though of and here it is for
those interested.
The purpose of this test is only to test the API between the dissectors
(packet-frame.c in this case) and
the tap subsystem (which is in tap.c and is a complete mockup) as well as
the API between the
graph extensions of which an example is in graph-fsh.c.
Also, this extension is always on. you can not enable/disable it using menus
as a real implementation
would allow you to.
This version does not contain a functional subsystem, only enough to drive
one single extension,
graph-fsh.c in this case. It does though call the redraw function in
graph-fsh.c once every 2 seconds so
the graph gets updated in semi-real-time. The graph is also updated
everytime I change the display filters.
Beware, it is a hack to test the design. Nowhere near anything that can be
used.
Oh, I must also note that barcharts in gnuplot are really ugly. Filled bars
are not supported ! ouch.
It is possible to run this code, just make sure to link with pthreads.
Please see what very minor changes needed in packet-frame.c to enable
extensions to tap data from it.
The tap is placed AFTER the frame is dissected in case the extension needs
any sort of data which is filled
in by any of the dissectors (which is not the case for this extension).
See packet-frame.c for this.
See graph-fsh.c for the actual extension. It is very small, only 109 lines
including the copyright/licence comment at the beginning.
Currently, this extension needs /usr/bin/gnuplot to be present to produce
the output. One could just as well
use any other external tool or viewer, preferably something available on
all/most of the platforms where
ethereal runs.
Pros as i see them:
* It would be very easy to implement simple extensions to present data in
graphical form or text statistics
without any knowledge in how to handle windows widgets etc.
* It does not rely on any specific widget set and would thus not prevent
someone from porting ethereal
to say KDE. (which I eagerly awaits)
* If a proper skeleton example is developed, it should be possible for
someone even without any deep knowlege
on how ethereal works or GTK to hack up a simple extension in a matter of
hours base on that skeleton.
Cons:
* It is completely non interactive.
* It is a one way presentation of data, it is not integrated in ethereal.
However, many types of graphs does not have any meaningful way to map back
into packets so
for these types of presentations of data, the proposed design would be
adequate.
Please review the changes in packet-frame.c and the file graph-fsh.c so we
can analyse the API to the
tap system.
I dont think we need something that integrates completely in ethereal for
these types of simple graphs/reports.
Attachment:
draft.diff
Description: Binary data
Attachment:
snapshot1.png
Description: PNG image
