|
Boost : |
From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2004-11-01 17:47:37
On Mon, 01 Nov 2004 21:32:26 +0200, John Torjo <john.lists_at_[hidden]> wrote:
> Johan wrote:
>
> > I basically was thinking about log "messages" as data structures,
> > consisting of least one message id (possibly consisting of facility,
> > severity and the id itself, similar to COM hresults and VMS status codes)
> > + insertion data. Logging a message would include creating an instance of
> > a log item and storing it in the TSS buffer for later retrieval,
> > formatting and writing by the worker thread. Data such as timestamps,
> > thread id, etc is added at this point and can be selected for
> > inclusion/exclusion in the actual writing on the back-end instead.
>
> So basically, after a message is added, a log_item is created, and
> different modifiers can fill different things of this log_item itself.
> Then, the appender(s) will decide which information to write to the real
> destination(s). This is an interesting idea.
This is how most of the logging frameworks I've used in the past have
worked. There's always a free-form text field for a human-readable
message, but there are numerous other fields which are filled-in
automatically (perhaps even down to the level of the __FILE__ and
__LINE__ where they were generated - very easy to do when using
macros).
Take for example the ACE_Log_Msg structure from the ACE library (just
the important bits):
class ACE_Log_Msg { [...]
// Status of last operation (user defined)
int status_;
// errno when this message was created
int errnum_;
// Line number in file_ where the message was generated
int linenum_;
// Name of file where message was generated
char file_[MAXPATHLEN + 1];
// The message itself
char msg_[ACE_MAXLOGMSGLEN + 1];
// Pointer to thread descriptor
ACE_Thread_Descriptor* thr_desc_;
// Priority (severity) of this message
unsigned long priority_mask_;
// Name of the program
static const char* program_name_;
// Hostname
static const char* hostname_;
};
No judgements of relative goodness/badness, just for informational
purposes. I would also suggest that any structured log message
contain a timestamp indicating when it was generated.
> Is this what you're talking about, or am I totally on the wrong track?
I think you've got the gist of Johan's point (assuming I have).
-- Caleb Epstein caleb.epstein_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk