Wireshark · Ethereal-dev: Re: [ethereal-dev] Preposal: ethereal.conf

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Sat, Jul 01, 2000 at 01:58:33AM -0700, Guy Harris wrote:
> I might suggest either that
> 
> 	1) there be both a "${libdir}/ethereal/ethereal.conf" file *and*
> 	   a "~/.ethereal/ethereal.conf" file, with settings in the
> 	   latter overriding settings in the former
> 
> or
> 
> 	2) there be a "${libdir}/ethereal/preferences" file, read by
> 	   Ethereal, the settings in which would be overridden by
> 	   "~/.ethereal/preferences", and with the settings in question
> 	   going into one of the preferences file.

I went with

	3) "${sysconfdir}/ethereal.conf" as the global preferences file
	   - "${sysconfdir}" is typically an "etc" directory, and
	   "preferences" is too generic a name, as there might be a
	   collision with some other program's file - and
	   "~/.ethereal/preferences" as the user's preference file.

The global preferences file is read first, if it exists, and the user's
preferences file is read after that, if it exists, so the user's
preferences override the global preferences.

> I would have the format instead being
> 
> 	<package-name>.<preference name>: <setting>

Done - the already-extant code is used to read both preferences files.

> (if the settings go into "preferences", this would require care to be
> taken that none of the non-dissector settings have package names that
> collide with dissector names - right now, there aren't protocols named
> "print", "column", "stream", or "gui", so we've avoided collisions so
> far).

I should probably add code to crash if a package has a name that
collides, so that the developer knows they need to pick a different
name.

> I might also
> 
> 	1) allow components of Ethereal to register settings by name -
> 	   and to register the component as well, giving both a name for
> 	   the preferences file and a human-readable name;
> 
> 	2) have said registration specify a data type for the setting,
> 	   e.g.:
> 
> 		integer (with a base specified as well)
> 		string
> 		Boolean
> 		enumerated (with a list of values specified as well)
> 
> 	   as well as a human-readable name for the setting.


Done.  I've modified "packet-ip.c" to use that mechanism to register the
"Decode IPv4 TOS field as DiffServ field" variable for IP as a
preference.

> Then I would be tempted to
> 
> 	1) have a "-o" command-line option to Ethereal and Tethereal,
> 	   allowing one to override settings from the command line,

Done.  "-o ip.decode_tos_as_diffserv:<value>" can be used to control
whether to decode the IPv4 TOS field as a DiffServ field; the values can
either be "true" or "false" (case-insensitive).  I.e.

	-o ip.decode_tos_as_diffserv:false

is equivalent to

	-D

You can, of course, also put

	ip.decode_tos_as_diffserv: false

into the global preferences file, to control the default state for all
users, or into your preferences file, to control your Ethereal/Tethereal
state.

> 	2) have tabs in the "Preferences" dialog for all components with
> 	   settings registered, with the tab having the human-readable
> 	   name for the component, and construct the tab based on the
> 	   data type and human-readable name, e.g. integers and strings
> 	   would be text entry boxes, Booleans would be check boxes, and
> 	   enumerated values would either be radio buttons or option
> 	   menus/combo boxes/whatever (perhaps the component would
> 	   specify which was to be used), allowing the user to change
> 	   settings from the GUI (with a callback to the component if
> 	   its settings are changed).

Done.  There's now an "IP" tab that pops up, with a check button to
control the setting of the flag mentioned above; "Save" will save the
setting to your preferences file.

> This would also obviate, in many cases, the need to have components
> parse the data themselves.

Sure does.  All the IP dissector had to do was:

	module_t *ip_module;

		...

	/* Register a configuration option for decoding TOS as DSCP */
	ip_module = prefs_register_module("ip", "IP", NULL);
	prefs_register_bool_preference(ip_module, "decode_tos_as_diffserv",
	    "Decode IPv4 TOS field as DiffServ field",
"Whether the IPv4 type-of-service field should be decoded as a Differentiated Services field",
	    &g_ip_dscp_actif);

which arranges that the Boolean variable "g_ip_dscp_actif" is controlled
by the "ip:decode_tos_as_diffserv" preference; in the Preferences dialog
box, that item appears as a check box (because it's a Boolean
preference) in the "IP" tab, with the label "Decode IPv4 TOS field as
DiffServ field".  If Ethereal writes out the preferences file, a comment
before it labels it as

	# Whether the IPv4 type-of-service field should be decoded as a Differentiated Services field

Stuff that still needs to be done:

	documenting the API for registering preferences;

	documenting the "-o" values in the man page (probably needs a
	flag similar to "-G", and a Perl script to turn the output into
	documentation as is done with the list of field);

	handling error checking for numeric values (range checking,
	making sure that if the user changes the variable from the GUI
	they change it to a valid numeric value);

	using the callbacks to, for example, update the display when
	preferences are changed (could be expensive);

	panic if the user specifies a numeric value with a base other
	than 10, 8, or 16.