On Fri, Dec 03, 1999 at 03:05:18AM +1000, Richard Sharpe wrote:
> Hi,
>
> finally, something that Guy suggested to me many months ago has sunk in.
>
> We have invested a lot of effort into Ethereal, but it does not provide the
> flexibility that I need.
>
> I envision the following program structure:
>
> while (get_next_frame(etc)) {
>
> decode_frame( ... , Level); /* These two might be in a call-back
> process_frame( ...);
>
> }
>
> Process_frame might display it the way Ethereal currently does, or might
> filter and write the selected frames, or might count frames with certain
> properties, etc.
>
> I would expect decode_frame to return a tree of attribute value pairs, and
> Level allows us to control how deep the decode goes, because for some
> things you don't need to go all the way.
I've been thinking about this too. The packet-* and proto-* routines, i.e.,
the decoding engine plus all the auxiliary files needed to support the
decoding should be in a separate library, libethereal. You either feed it
a frame, or it gets one via wiretap, decodes it, then passes back the
dissected protocol tree.
Then we'd have GUI routines to provide the user interface as it is now. Or
we could even write the GUI routines in a scripting language.
In the future we'd have some curses-based UI routines, for a text interface.
In the future we'd have a guile wrapper, to provide a command-line, interactive
interface.
We'd write a perl wrapper so that Gerald could write a CGI script using
Net::PacketDecode (just to pick a name) to do on-line packet decoding on
ethereal's web page, before RADCOM implements theirs (I believe it's them
that has it on their webpage that they're going to do that sometime in the future).
--gilbert
