Rework the suggested logger implementation to one that doesn't suck donkey and flesh it out a little more. I actually think this is a workable idea now, and I might start on it sometime soon. :-)

git-svn-id: http://svn.inspircd.org/repository/trunk/inspircd@8847 e03df62e-2008-0410-955e-edbf42e46eb7

1 files changed, 18 insertions, 5 deletions

diff --git a/src/logger.cpp b/src/logger.cpp
index 600f29242..690c1a5d9 100644
--- a/src/logger.cpp
+++ b/src/logger.cpp
@@ -18,13 +18,26 @@
 /*
  * Suggested implementation...
  *	class LogManager
- *		LogStream *AddLogType(const std::string &type)
- *		LogStream *DelLogType(const std::string &type)
- *		Log(LogStream *, enum loglevel, const std::string &msg)
+ *		bool AddLogType(const std::string &type, enum loglevel, LogStream *)
+ *		bool DelLogType(const std::string &type, LogStream *)
+ *		Log(const std::string &type, enum loglevel, const std::string &msg)
+ *		std::map<std::string, std::vector<LogStream *> > logstreams (holds a 'chain' of logstreams for each type that are all notified when a log happens)
  *
  *  class LogStream
  *		std::string type
- *		(void)(*)Callback(LogStream *, enum loglevel, const std::string &msg) <---- callback for modules to implement their own logstreams, core will just handle to file/channel(?)
+ *      virtual void OnLog(enum loglevel, const std::string &msg)
  *
- * Feel free to elaborate on this further.
+ * How it works:
+ *  Modules create their own logstream types (core will create one for 'file logging' for example) and create instances of these logstream types
+ *  and register interest in a certain logtype. Globbing is not here, with the exception of * - for all events.. loglevel is used to drop 
+ *  events that are of no interest to a logstream.
+ *
+ *  When Log is called, the vector of logstreams for that type is iterated (along with the special vector for "*"), and all registered logstreams
+ *  are called back ("OnLog" or whatever) to do whatever they like with the message. In the case of the core, this will write to a file.
+ *  In the case of the module I plan to write (m_logtochannel or something), it will log to the channel(s) for that logstream, etc.
+ *
+ * NOTE: Somehow we have to let LogManager manage the non-blocking file streams and provide an interface to share them with various LogStreams,
+ *       as, for example, a user may want to let 'KILL' and 'XLINE' snotices go to /home/ircd/inspircd/logs/operactions.log, or whatever. How
+ *       can we accomplish this easily? I guess with a map of pre-loved logpaths, and a pointer of FILE *..
+ * 
  */