Ethereal-dev: Re: [Ethereal-dev] RFC framework for graphical extensions like the recent rate_
On Tue, Jun 25, 2002 at 08:14:46PM +1000, Ronnie Sahlberg wrote:
> I made up the following desireable requirements for these kind of
> extensions:
I agree
> The best I could come up with would require we first port ethereal to use
> GLIB2.0 (only GLIB, GTK not required) since GLIB2.0 supposedly have thread
> support on all supported platforms
A agree again, that we need several threads/processes to implement the
solution you present below (or any usable solution I could come up with).
> Well let me explain the design i came up with and everyone else that is
> interested can say why my idea sucks and why it is broken and come up with
> better ideas.
What sucks :-)
- I hate busywaiting! This should be event driven.
- Function overloading with flags (startstop). They should be separate.
OK, let me just summarise, how I imagine this could work, very much
inspired by your iedas:
- register/deregister on program startup/shutdown (in case of a plugin
on load/unload).
- event whenever we start a new trace
- event whenever we stop a trace
- event whenever we change a filter
- event whenever a new packet has been received (before/in order to
dissect it)
- event whenever a new packet has been dissected
- event when a certain time has elapesed (timer)
- event when we have been configured (gui)
- event when a certain filter condition has been satisfied (see below).
Carrying the idea one step forward, I think that the actual display
of the dissected data should be just another one of those modules.
Infrastructure improvements:
One more thing to make statistics more efficient: How about a real
statistics tree? Right now, whether a packet shows in our statistics
or not is just a matter of whether anyone wanted the data in ethereal
badly enough to add another line. How about adding the "accounting" into
each dissect_... function?
And another one: Some sort of generalized display filter, i.e. in case
we have that plugin mechanism, I'd like to see the matching checks
performed once per packet and not once per packet and plugin (of course
only plugins that want some specific information). In case a match is
found, just send me an event.
That is all I can come up with for now.
Ciao
Jörg
PS: Maybe we should release version 1.0 before such a thing?
--
Joerg Mayer <jmayer@xxxxxxxxx>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.
