Enough said, I am coming from a support role and analyze hundreds of
traces per month for many different customers. I have ran into this issue
several times and thought I would ask for opinions. Perhaps the issue is not as
bad in Unix environments as it is in Win32. The bad thing is for anyone
downloading Ethereal and attempting to open a trace that was not captured on
their local network. They will think that Ethereal is a dog since it takes
forever to open a trace. :@(
>>> Joerg Mayer
<jmayer@xxxxxxxxx> 09/23/02 10:19AM >>>
On Mon, Sep 23, 2002
at 09:43:31AM -0600, Greg Morris wrote:
> Yes, I know that you can turn
this off... I was requesting that it be
> turned off by default and that
if someone wants this capability they can
> turn it on. Perhaps what might
be a better solution is that the name
> resolves be enabled by default on
capture and disabled by default on an
> open... What do you think?
:@)
Greg, while this may look ok at first glance, I'm a fan of
orthogonal
command line options (which we don't have but I don't want to make
things
worse), so changing the default behaviour depending on whether we
are
doing one thing or another is not a good idea.
Another thing you may
want to consider is, that while there is an option
to turn all resolving off
(-n), there is no option +n (well, actually
there is in the form of
-Nmnt).
In case you really want to make such an incompatible change, you have
to
take into consideration that tethereal is used in scripts.
That said:
In case we really start making incompatible changes to the
ethereal command
line handling, I'm not really opposed to it but then
we should change quite a
few things in addition and print out a fat
warning whenever the new version
is started.
Ciao
Jörg
--
Joerg
Mayer
<jmayer@xxxxxxxxx>
I found out that "pro" means "instead of" (as in
proconsul). Now I know
what proactive means.
|
