[slf4j-dev] what are we here for?

[robert burrell donkin]

On Sun, 2005-05-01 at 21:03 +0200, Ceki Gülcü wrote:
> At 20:52 5/1/2005, robert burrell donkin wrote:
> >the JCL proposal document has proved pretty successful over the years. i
> >have a few suggestions arising from that.
> 
> The JCL proposal document. Any quick link?

unfortunately, only through SVN

http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/logging/trunk/STATUS.html?view=markup

http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/logging/trunk/PROPOSAL.html?rev=155426&view=markup

this paragraph from the user guide seems reasonably phrased:

"The Jakarta Commons Logging (JCL) provides a Log interface that is
intended to be both light-weight and an independent abstraction of other
logging toolkits. It provides the middleware/tooling developer with a
simple logging abstraction, that allows the user (application developer)
to plug in a specific logging implementation."

> 
> >i think that the word 'thin' is important. it's also important to
> >emphasis that provision of logging system functionality is an anti-goal
> >as is defining some sort of common configuration system for logging
> >systems. these have saved a lot of hassle over the years.
> 
> Yah, that much is pretty clear at this stage. Having said that, one day in 
> the future, we might have a situation where different framework 
> implementors come to us and say, we agree on such and such interface for 
> configuration, can you accommodate us? I don't think we will close the door 
> to their faces. But again, that day may never come.

configuration is the most commonly requested feature for JCL. but
implementing it would cross an important line leading to an endless
battle against code bloat and feature drift. explicitly excluded this
possibility in the proposal was definitely the right approach. 

over the years, i've been persuaded that thin really needs to mean
*thin*. any extra baggage limits the applicable scope for a logging
bridge. therefore, if a need for a common configurator for logging
systems was demonstrated (as in your example), i would advocate a
separate definition as opposed to integration. 

one of the factors in the success of jakarta commons has been the
insistence that scope for components be both clearly defined and
strictly limited. this approach has both created better components and
also saved a lot of time over the years. 

i can understand long term ambitions to extend this approach (if this
process proves successful) to other related areas. however, i would
suggest that it makes more sense to separate a broader mission for the
project from a narrower one for a simple logging API. 

> >i been pondering whether we might actually be better concentrating on
> >defining rather than providing. it may be possible to use take the
> >static binding strategy even further and define nothing but the kernel
> >API.
> 
> Are you suggesting of providing something like a ULogger [1] interface and 
> nothing else?
> 
> [1] http://www.slf4j.org/api/org/slf4j/ULogger.html

i'm not trying to advocate any particular approach, it's just a language
thing. using the word provider will necessarily exclude some
possibilities from discussion. IMHO the word define is more neutral and
gives more freedom.

- robert