Ethereal-dev: Re: [Ethereal-dev] Split the capture-child into it's own program?!?
LEGO wrote:
I do not have good Ideas for a name, but I have thought of an
interface to the caller program (etheral) of this type of capture
agents.
when called without any arguments it should give back to the caller a
parseable list of arguments and the types of those arguments and
whether they are mandatory or not.
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.
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.
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.
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 ...
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.
Regards, ULFL.
