bmon TODO/Wishlist 
==================

1: Differ between interactive and non-interactive output modules

	Currently the timing is done by sleeping in small amounts and
	check if the next read interval has been reached. The sleep
	amount gets adjusted to hit the next read interval as accurate
	as possible.

	This is only needed for interactive output modules. Non-interactive
	output modules could enforce a timing strategy which would sleep
	exactly to the next read interval and thus save some cycles.

2: Discard outdated rate updates

	The new input modules are not reliable anymore due to network
	delays etc. Outdated updates should be discarded to avoid
	corruption of the rate estimator.

3: XML Output Modules

	bmon's portability advantages could be used to provide all the
	architecture specific interface statistics and convert them to
	a generic XML based interface. There should be interfaces:

	a) Update based

		Every update gets written to a file descriptor as XML message
		which can be used to reproduce the interface flow at a later
		time. This way one can record the bandwidth consumption during
		tests and analyze it later together with additional data of
		the test.
	
	b) State based

		The current state as it would be outputed by bmon itself
		written as XML message and overwritten in every output
		interval (just like the already implemented HTML output).
		This could be used by 3rd party applications to display
		the current statistics and rate estimations.

		Problem: Locking

4: SNMP Input Module

	A SNMP input module (secondary) would increase the usefulness
	in environment with properiatary hardware to which bmon
	cannot be ported.

	Problems:
	a) Async nature

		The whole module must be implemented async, this itself is
		not a problem but the protocol enforces various handshakes
		required to get the statistics:

		1) Get number of interfaces
		2) Wait for the result (could be cached)
		3) Request statistics
		4) Wait for the result
	
	b) Accuracy

		Due to the handshakes required the accuracy can vary depending
		on current network latency and it is quite hard to adjust it.
		Other statistical applications using SNMP don't have this problems
		because they don't require update intervals of <= 1 second.
	
5: Configurable Graph Statistics

	Currently only the byte counters support graphs. It would be nice
	to have this configurable and let the user specify which counters
	he would like to see graphs for. There are various ways to
	implement this:

	a) Decision at boot time

		Let the user specify a list of attributes he want to record
		history on it. Depending on the list an attribute allocates
		either a single counter or a set of arrays to store a history
		of the counter to later calculate the graph.
	
	b) Decision at runtime (immediate display)

		Every attribute gets its history stored. This results in
		massive consumption of memory with the advantage that every
		attribute has a graph available immediatly.
	
	c) Decision at runtime (delayed)

		The bytes attribute has its history stored as usual, additional
		attributes may be requested to store history and their container
		gets reallocated to store history from now on. The graph will
		only be available from the time the graph was requested.
	
	d) Combination of a and c with runtime option to achieve b

		The user may specify a list which will store history from
		the very begin. He may also decide to do so for all attributes
		by specifying "all" in that list. Additional attribute may
		be requested to begin store history during runtime and
		requested to stop doing so. This is the most complex but also
		most powerful solution which should suit everyone.
