Ronnie Sahlberg wrote:
...
This looks pretty good.
> 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)
Me, too.
> * 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.
Yes. It might even be farily easy to develop someting somewhat generic.
>
> Cons:
> * It is completely non interactive.
Yes, but some data such as counts and rates do not need to be
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.
See above. It would surely be adequate for a first step. The design
does not preclude adding interactive graphs later. Also, with the use of
an external program (which could be changed via a pulldown or entry) the
executable is not filled with code some may not use.
> I dont think we need something that integrates completely in ethereal for
> these types of simple graphs/reports.
As I noted, I agree that there are plenty of types that don't need
interaction. It would be nice for some types, but where there are
counts, rates, or other data where plot points don't map back to
individual packets, this design seems useful.
--john
--
John McDermott, Writer and Consultant
J-K International, Ltd.
V +1 505/377-6293 F +1 505/377-6313
jjm@xxxxxxxxxx