On 11/18/05, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> It's a bad approach to do this kind of output if no option is used, this
> way no human user of the (new) standalone capture program get's a
> meaningful help. Using a special option for this output is a much better
> idea.
Ack
> How do you want to find an automatic way to display these options to the
> user?!? You would have to supply valid ranges for each option, find a
> way to layout the options to fit into a reasonable display space while
> still be usable, ...
>
> Did you have a closer look at (the amount of) the current code of the
> capture options dialog? This is handcrafted code to display all options
> in a smooth way, so doing this in a programmatic way which is still
> usable is just impossible in my eyes. Well, simply forget about this
> (much too) simple approach IMHO.
I actually took a look at it, the upper pane (Capture) of the "Capture
Options" dialog could be easily described as:
-i interface<"en1","en0","lo0"> -l
link_layer_header_type<"Ethernet","NULL"> -p promisc<bool> -s
limit_each_packet_to<68-65536> -f capture_filter<string>
We need just to parse that (I can write the parser myself) and add the
items to the pane the next y pixels bellow the prior while drawing the
dialog.
We loose the match between the link_layer_type and the interface,
that means that an user could set NULL as the link layer type of an
ethernet interface, but then the agent would report back the error to
the user.
The "Capture File(s)", "Stop Capture", "Display Options" and "Name
Resolution" panes should come bellow the generated pane.
Once accepted the dialog call back should format the argument string
with which to call the capture agent again.
The capture agent would do just that, capture and feed the client
(ethereal). The rest of the functions (stop, file writing, dissection,
display, etc) will stay in the client (ethereal).
It's simple but not simpler than needed.
> What might be an idea is to create a plugin interface for capture
> childs, including a GTK part for the options dialog. But there are *a
> lot of issues* to be discussed before taking this approach, and I don't
> want to discuss this now.
I was thinking in external capture agents that might be writen even in
perl or the like for things like fetching and massaging logfiles. No
GTK, no glib... as I said maybe not even in C.
>
> BTW: it's happen again and again (and I'm feeling really tired about
> this): people tend to discuss things how the world could be, but "no
> one" is actually doing anything to achieve improvements ... This way a
> lot of hot air is produced, but no real improvements are done, our
> mailing list archives (and the WishLists) are full of such discussions
> without any real effect ...
A universal thruth is that the S/N ratio is always going to be lower
than we like it to be.
Ideas should be discussed even if they are to be discarded. That is
much like diamond mining, you have to get tons of worthless coal out
of the mine to find a diamond.
Thanksfully, not every thing that gets discussed it's actually done...
Trust me, there's never going to be a shortage of bad ideas. :)
I thought this one was worth being exposed. Personally I don't think
it's a bad one at all.
> Even the solution I've outlined in my previous mail will take days to
> implement (and weeks until it's really stable again?) and this work has
> to be done first, regardless of any further steps. If I (or someone
> else) finds the time to do the job, we might be able to discuss things
> further, but please don't discuss this things before it's time has come.
Having pluggable capture agents is something I been thinking about for
a while, and I believed its time had come... I might even find the
time to do some parts of the job.
L.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan