[slf4j-dev] Re: Beta 4 and the new method signatures

[Ceki Gülcü]

At 05:45 PM 7/11/2005, Greg Wilkins wrote:

>Ceki,
>
>it's good to participate in a receptive discussion.... even if the end product
>is to keep the current API as it is.

:-)

>I kind of consider that the only true method in this API is
>log(String) and the others are just conveniance methods for
>effecient formatting.

Me: nods in approval.

>So I do think that log(String) is appropriate for a request log,
>as is isEnabled().     I could even make a case for log(String,Throwable)
>if I was to have a request log that did not conform to NCSA format.
>
>I could also live with log(Object) as the fundamental methed,
>but slf4j appears to take that approach that logs are for strings not objects.

Yes, developer logs are for strings, not objects; a choice with not so
innocuous implications.

Even if log(Object) existed as the printed basic method, I believe
that one could not build interchangeable logging systems for different
purposes all adhering to the same abstract (as your simple Log) API. This is
not to say that such systems could not be built. They obviously
can. However, I think they cannot share the same client API, although
they may perhaps share components.

The scope of SLF4J API does not cover request logs. As I see and
understand the general problem of logging, it is impossible to come up
with a single client API to cover all use cases. By the way, I
encourage everyone to prove me wrong.

[snip]

>I still think it is a good question to ask - why does the current API
>force the same scope on debug, info, warn and error?
>Is it just for simpicity of usage or is there another reason to tie
>their scopes together?

Because for developer logs, the ordered level and hierarchical logger
paradigm covers a lot of ground. As you mentioned, however, it cannot
be generalized to suit other contexts.

>Hence my suggestion of looking for a way to do both.   The current "fat" API
>is perfect for 90% of common usage give or take a few niggles about trace.
>
>But because of it's fatness it is difficult to extend and uncomfortable to
>use in some use-cases.    So if there is a layer that we can peal off the 
>"fat"
>API and reveal an underlying "thin" API then that can be used for the more
>complex use-cases.
>
>So the question is - is there such an underlying "thin" API? and is there
>enough need for it to make it worth the complexity of exposing it?

Good question. In my humble opinion, the various use cases cannot be
abstracted into a nice, generic and highly abstracted API. Needless to
say, it would be extremely nice if such an API existed.



>--
>Greg Wilkins <gregw at mortbay.com>

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/