[Guy Harris <gharris@xxxxxxxxxxxx>]

On Sat, Jul 01, 2000 at 12:16:38AM -0700, Guy Harris wrote:
> 

Well, let's try this again:

On Thu, Jun 29, 2000 at 07:53:10AM -0500, David Frascone wrote:
> Ben Fowler <wapdev@xxxxxxxxxxxx>, came up with a great idea!  A place for
> dissectors/etc to read their settings from, ethereal.conf.
> 
> So, I prepose this: a file, ethereal.conf, with the following format:
> 
> <package-name>:<argument string>
> 
> It would be placed in /usr/local/lib/ethereal/ethereal.conf

...which wouldn't allow different users on the same machine to have
different settings for the parameters.

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 use "${libdir}" to refer to the directory in which the file appears -
it might be "/usr/lib" if Ethereal was configured to be installed in
"/usr/lib", or, instead, we might go for "/usr/share" or
"/usr/local/share", as, so far, all files in "~/.ethereal" are, I think,
text files, and thus shareable between different platforms.)

I would have the format instead being

	<package-name>.<preference name>: <setting>

(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 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.

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,
	   e.g.:

		tethereal -r <file> -o xxxp.port:13706

	   to set the port for the XXX protocol to 13706;

	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).

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