On Sun, 30 Dec 2007 18:55:22 +0100, vseguip@gmail.com wrote:
Anyway, is there a more elegant way to turn logging off than simply redefining the method?
Sure. There are several ways to control this:
http://weitz.de/hunchentoot/#log
You could for example turn access log messages off. Of course, once you have your 300-visitors-per-second website, you probably /want/ logging... :)
I think the fact that log-message is locking when logging to a file makes it take a sever performance hit, maybe the use of a logging framework that solves this would be nice.
Yes, maybe. Is there a mature, stable, well-documented logging framework out there that works with all Lisps supported by Hunchentoot? How would such a framework deal with several threads trying to log at the same time if not with locking?
One could also think of a setup where there's one dedicated logging process and other processes write to the log file by sending objects to its mailbox:
http://cl-cookbook.sourceforge.net/process.html#mailbox
(Or use cl-muproc? Maybe a bit of overkill.)
But that would cancel the support for non-threaded Lisps we have now and it would introduce more implementation-dependent code.
Anyway - not a big priority for me. If it's important for you, I'd suggest you make a detailed proposal, we discuss it here, then you send a clean patch.
On a side note, I wanted to comment some refactoring to hunchentoot that I think may make sense. Right now process-connection is a function that takes care of reading from the client, be it via mod_lisp or directly, binding the chunga/flexi-streams if needed and dispatching it. I think a better design would be to make process-connection a generic method on class connection and then implementing methods for mod_lisp/standalone/fastcgi/whatever. Chunga and flexi-streams wrapping could be implemented as mixins so the user can choose to create a FCGI connection with flexi but not chunga, etc. With this we can allow for custom backends to be developed by users so we gain flexibility (and maintainability) at the cost of some overhead when dispatching. What do you think?
I'm always open for changes which improve flexibility and maintainability and at first sight your proposal sounds fine to me. If you want to implement that, I'd suggest to proceed like I described above.
Edi.