RE: [boost] Logging library - Organization of effort

From: Otto Hirr (otto.hirr_at_[hidden])
Date: 2002-04-10 11:15:13

> Behalf Of Ernie Makris
> Sent: Wednesday, April 10, 2002 7:00 AM
> Subject: [boost] Logging library - Organization of effort
>
> Also, everyone has an implementation. Which is good. I think
> this is a natural thing. Almost everyone has either implemented
> or used some logging library. We will have many different designs
> to look at.

The strong point of this is that we can learn from others as to:
  features they had >and used<
  features they had >and did NOT use<
  features they wish they had
The weak point of this is that without some kind of up front
design it simply becomes a committee hack.

> The question now is, how to proceed.

Someone should capture the commonalities and differences between
implementations, distilling out some kind of feature taxonomy.

> For the first revision of the library, I think we should not
> go overboard. I think we should concentrate on creating a simple
> design with out all the bells and whistles (i.e. sinks that output
> to a database).

Here I assume that your reference to bells & whistles would be
like to a database or some other super-duper mechanism.

Here I would have to disagree!
IF properly designed, it would not matter.  The logging mechanism
must be able to place the "message" (say a simple string) to some
place, like a file.  Fine, the file has to be opened before use
and the file descriptor stored somewhere.  If properly designed,
it should be >>transparent<< so that later change the message would
route to a database, socket, orb, etc.  It should not matter.
The big issue is what winds up in all the instrumented source code
should not have to change just because we are now sinking to
a db, socket, etc.

The interface to the logging mechanism that is used in source
code should remain constant.

> whether it is logged both at compile and runtime.

A feature taxonomy.

> If we focus on a clean design that allows for all the
> extensions that we all
> know and love, we should be able to satisfy the majority, I think;)

Bingo!

> There are many design styles that can be considered in the
> design of this
> library. So I propose an initial discovery phase roadmap:
> 1) Evaluate existing designs
> 2) Create brief requirements and objectives document
> 3) Experiment
>
> I also like to comment that I don't want to be part of a
> massive design by committee. This is type of library that
> can very easy to fall  into that trap. Lets focus on the basics first.

Again, I think the most critical issue becomes what is placed
in source code, 'cuz no one is going to want to go back and
change it later if the interface changes.  (The implementation of
the logging mechanism is hidden - right? - 'cuz were object-oriented
folks :-)

> Also, just so that everyone knows my bias, I dislike macros.

Here - here !  Just make a solid interface.

> I think we should do as much as we can without them and only use them
> sparingly. We should leverage templates where macros have traditionally
served.
>
> What does everyone think?

Well now you got my 2 cents.

Best regards,

.. Otto

Otto Hirr
OLAB Inc
503.617.6595
otto.hirr_at_[hidden]