Re: supporting extend 'open live capture' parametes

[Guy Harris <guy () alum mit edu>]

Michael Richardson wrote:

> What problem is the ultra-open parameter list supposed to solve?

1) allow open options to be added without having to change the signature 
of the open-live routine, so that we don't have to anticipate all the 
options that might ever want to be added.

2) allow a application to inquire which particular options are available 
for a particular device, so it could, for example, not present UI for 
turning on 802.11 monitor mode if it's not available, and present UI for 
selecting an 802.11 channel to monitor that shows only the available 
channels, or, for a command-line utility, list the available options for 
a particular device.

And possibly 3) allow options to be selectively supplied, so that we 
don't have to come up with "no value supplied" values for options that 
an app might not supply (e.g., buffer size for an app that wants the 
default).

> My experience is that you either make it a structure and deal with
> possibly versioning it,

I.e.:

        struct open_options {
                int     version;
                /* actual options follow */
        };

        struct open_options_v1 {
                int version;            /* = 1 */
                options go here;
        };

        struct open_options_v2 {
                int version;            /* = 2 */
                a bigger set of options go here */
        };

> you make it a string and let the library parse
> it, or you go whole-hog, and make it XML.

It's probably easier to construct the option list then to construct the 
string, and to parse the option list than to parse the string 
(especially if it's XML).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.