Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
mc-logger (mc for "multi-contextual") is a logging library with unconventional features, in early stages of development. It intends to support a much better-structured and comprehensive form of logging than conventional "one-string-at-a-time" libraries.
Common Lisp
branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
.gitignore
README
UNLICENSE
main.lisp
mc-logger.asd
package.lisp

README

Hosted at: http://github.com/Hexstream/mc-logger


mc-logger (mc for "multi-contextual") is a logging library with
unconventional features, in early stages of development. It intends to
support a much better-structured and comprehensive form of logging
than conventional "one-string-at-a-time" libraries.


The central part of the design is that "one" logging operation can
take an arbitrary amount of time and output arbitrary amounts of
details. The rest follows logically from there.


Planned features include:

- the ability to output one "logical" logged message in multiple
  output operations instead of one. Useful for logging complex
  operations. The one logical message will be transparently
  reconstructed from its parts when loading the log file;

- the ability to output to multiple independent logging contexts
  concurrently. Each time you log something you specify a context, and
  a "context-switch" will occur if the last logged item was part of
  another context. This context "multiplexing" will be transparently
  "demuxed" when loading the log file;

- the ability to nest logging contexts.


Here's an example scenario.
I show the nesting of contexts right after each event:

;; You start the server
Server1
;; A request is initiated.
Server1 --> Request1
;; The request was a form submission, so we start form validation.
Server1 --> Request1 --> Form1
;; Now, another concurrent request is initiated.
;; A new context is created and a context-switch occurs.
Server1 --> Request2
;; Form validation succeeds for the first request. A context-switch occurs.
Server1 --> Request1
;; Page rendering is starting for the second request. A context-switch occurs.
Server1 --> Request2 --> Render1
;; Page rendering finished for that same request.
Server1 --> Request2
;; The connection was closed for that same request.
Server1
;; Let's say the first request does no rendering because it's a redirect.
;; Because that example is getting too long for my taste.
Server1
;; Now you stop the server. We're back to the "root" context, or something.
;; Which was implicit so I didn't write it out every time.

And remember that there can be any amount of messages/details at each
step. You might have a new context with many messages inside where
you'd normally only have one message without opening a new context,
depending on if you have more detailed logging turned on or off,
respectively.

If you're logging at a finer granularity, you'll have more context
nesting. If the granularity is very coarse, you might not bother
opening new contexts at all and your log file will be very similar to
conventional, "flat" log files.



This library is in the Public Domain.
See the UNLICENSE file for details.
Something went wrong with that request. Please try again.