logging system needs better types

[FellowTraveler]

Currently there is a distinction between Error and Output which is simple: stderr and stdout.
(The idea is that only REAL output should go to stdout, and logs should go to stderr.)

There is also an OT_ASSERT which is a bit different than those.

We also currently have LOG LEVELS, with 0 always showing, and each successive higher number being less and less visible.

===> WE NEED MORE THOUGH:
===> There needs to be distinguishing between logs of ERRORS, FAILURES, SUCCESSES, WARNINGS, ACTUAL OUTPUT, and RESPONSE.

===> Errors and failures are different. Just because you failed to open a certain filename doesn't mean that an error occurred, it just means the file wasn't there. That's not an error. Whereas if you tried to open a file, and it WAS there, and there was a hard drive error, you would get an error code, which is VERY DIFFERENT than a failure (say because the file wasn't there.)

===> I say this because for example, certain replies might be sent back to the user. Like the server might do this:

if (error)
OTLog::Error("An error occurred!");
else if (not enough funds)
OTLog::Failure("Insufficient funds.");

The first log should go to the server's error logs, for the server administrator.
But the SECOND log, should be attached to the reply, back to the user! (And perhaps logged to a separate logfile, to boot.)
We certainly can't send the user ALL of the logs indiscriminately, but we should be able to have a CLASS of logs that are specially used for this.

===> Successes can also the sent to the user. Often these logs are not shown by default, since most things succeed and we don't want to flood the logs, so we put them as "Output" at log level 4 or 5, so no one ever sees them.
===> But the proper way would be to have an OTLog::Success(); log. Level 0 would be financial results, and would be returnable to the users. Level 1 and higher would be various other successes, not sent to user, since we don't want to show him ALL the function successes. But we can still output them, log to success file or to the main log when debugging, etc.
===> Might differentiate further: Success()ful for functions, and SuccessResponse() to user. (and FailureResponse()).

===> CURRENT system is a problem because is a success really an OUTPUT?

===> "Success creating new cheque. Here is the cheque: "

===> Point being, the CHEQUE ITSELF was probably the output requested by the user when he typed "ot --cheque". That is REAL output. Perhaps the user is PIPING that cheque into another command-line program!

===> Therefore I can't just put cutesy "Success creating new cheque" text INTO that output. It's a LOG, not output! But do I want to stick it on stderr, if it's not an ERROR? (It's a success message...)

===> The answer is, I should log the message to stderr, and log the cheque to stdout, and then I should have BOTH appear at the console, streaming together. But I should also have the ability to stream them to different files.

===> The responses, the successes, the failures, the warnings, the errors, they should ALL go to stderr, AS WELL as options for their respective log files. Only ACTUAL output should go to stdout. And it needs its own special function for doing so.

===> Is there some standard class that does this already?