On Sat, Jul 14, 2001 at 12:20:27PM -0700, Guy Harris wrote:
> > It seems to me that some of us are so
> > consumed by all of these fancy new dissectors and their supporting
> > infrastructure that they tend to miss the point of network traffic
> > analysis.
>
> What is "the point of network traffic analysis"?
That's an unfortunate wording for simply "getting results". What I
wanted to point out was that end purpose of any piece of software
including ethereal should be to enable users to get the results they
need. This sounds obvious but it's worth restating now and then. I have
to remind myself sometimes that the software I'm writing is not created
to be beautiful, it's created to be useful in the first place. The rules
of modular design, Unix philosophy of "filters" and thing like that were
devised to serve the end purpose of software, which is being useful (in
the broadest sense of the word). We make software "beautiful" or "clean"
just because our experience tells us that clean designs are simpler to
maintain, evolve, less prone to bugs etc. - in other words, they
contribute to usefulness.
*Please* don't take this as a flamebait. I'm just trying to speak my
mind here, not to educate you about things you've long known.
> Different users have different reasons why they use a network analyzer.
>
> I am a software developer at a manufacturer of, well, Network
> Appliances; the reason why *I* use a network analyzer is to look at
> specific problems, which often involves looking at a specific trace in
> detail.
>
> Others may be doing broader analyses, e.g. statistical analyses.
Yes. I'm not trying to tell you that you need my or any other plugin
code. I was pretty content with basic dissecting for quite a long time
myself. I'm just trying to tell that we should do our best to support
*all* the user's needs, everything that sounds remotely reasonable
should be taken into account.
> > Support for some sort of API
> > I'm talking about, however limited, and a couple of obvious callback
> > points in the packet processing chain would enable people to use your
> > program in a way you've never dreamt of.
>
> Or, alternatively, making the stuff in the epan directory a library, and
> either having a separate library with the dissectors, putting the
> dissectors into the library as well, or making them all loadable at run
> time by that library, and having people build *multiple* programs from
> that library, would enable people to use our code in ways that Ethereal
> doesn't.
That would be definitely very beneficial.
> It is not *ipso facto* the case that Ethereal needs to Do It All by
> itself. It may be that some or all other analysis functions are best
> done inside Ethereal - for example, as the TCP graphing stuff connects
> the packet list and the graph, it may be that it's best done inside
> Ethereal - but I'm not going to take as a given the notion that
> all forms of network traffic analysis should be done by Ethereal as a
> program. (I won't necessarily reject all attempts to put forms of
> analysis into Ethereal; I'm merely not going to take as an
> unchallengable axiom the notion that they *should* all be put in there.)
I agree. Definitely not everything belongs to ethereal itself. But even
if it is better to put some functionality into a separate program that
will run as a separate process I would consider at least giving the
external program a menu item in Tools (or somewhere else) and supporting
"transparent" launch of the program. By "transparent" I mean not
requiring the user to explicitly save the dump, then launch the external
program with the file as an argument from the command line, I mean
giving the user a menu item that would save the dump automatically into
/tmp (or somewhere else), run the external program with appropriate
arguments and delete the dump after the child exits. Of course,
sometimes even this could be hairy but it's definitely worth considering
because things like that can win ethereal the power users - people that
use ethereal 4 or more hours a workday for solving difficult to spot
network problems.
