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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
