Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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. http://worknotes.hexstreamsoft.com/li…
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Type||Name||Latest commit message||Commit time|
|Failed to load latest commit information.|
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.