[Live-devel] [PATCH] Enable logging levels, part1

Ross Finlayson finlayson at live555.com
Thu Jul 1 15:57:37 PDT 2010


>There are many calls in form envir() << something; or similar. These messages
>are either emitted or could be completely disabled by subclassing
>[Basic]UsageEnvironment.

The intention of the "UsageEnvironment" virtual base class is to 
allow various environment and application-specific custom behaviors 
to be implemented by defining and implementing a custom subclass of 
"UsageEnvironment" (or perhaps a subclass of "BasicUsageEnvironment", 
which is the 'default' subclass that we provide).  Ideally, this 
avoids the need to have to make custom modifications to the provided 
library source code (the "live/" directory), which is something that 
I hope can be avoided as much as possible.

In particular, the intention was that any custom output ('logging') 
mechanism that you desire for your own application code could be 
implemented by subclassing "[Basic]UsageEnvironment", and 
reimplementing the various "operator<<" virtual functions.  There 
should be no need to introduce a second customizable virtual base 
class (named "Logger" or anything else) that developers need to 
concern themselves with.  One customizable virtual base class 
("UsageEnvironment") should be sufficient.

So, your starting point should have been not to modify the provided 
code, but instead to try to get the functionality that you want by 
creating your own subclass of "[Basic]UsageEnvironment", and 
reimplementing the various "operator<<" virtual functions.

How to do this?  One possibility is to add (to your 
"[Basic]UsageEnvironment" subclass) a member function:
	setLoggingLevel(logLevelType level)
and call
	yourEnvir.setLoggingLevel(someLevel);
before each call to
	yourEnvir << someOutput;
in your application code.  Note that this would only be for *your* 
code; the existing (provided) code would not change.  Therefore, you 
would need to have some 'default' logging level that would be used by 
all calls to "envir() <<" in the provided code.

A cleaner and more sophisticated approach, however, would be to 
define new operators specifically for logging, so you could do (for 
example):
	int msgNum = 42;
	yourEnvir << log(someLevel) << "This is a log message number 
" << msgNum << endLog;
By defining something like:

YourUsageEnvironmentSubclass& log(YourUsageEnvironmentSubclass& env, 
logLevelType level) {
	env. setLoggingLevel(level);
	return env;
}

YourUsageEnvironmentSubclass& endLog(YourUsageEnvironmentSubclass& env) {
	env. setLoggingLevel(TheDefaultLevel);
	return env;
}


Having said all this, I do admit, though, that the 
diagnostic/debugging output in the provided code is a bit 
inconsistent right now: Some parts of the code use #ifdef 
DEBUG/#endif, and other parts use a 'verbosity level' variable to 
enable/disable diagnostic/debugging output.  Over time, I will likely 
be making this more consistent (most likely by making more of the 
code use 'verbosity levels', and perhaps moving the 'verbosity level' 
variable into "UsageEnvironment").  But I'd prefer not to make any 
such changes right now, which is why I suggested above that you make 
the existing code use some 'default' logging level (that you can 
choose to do whatever you like with).
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


More information about the live-devel mailing list