[slf4j-dev] what are we here for?

[robert burrell donkin]

ceki - care to post up a new strawman definition to try to kickstart
this process into life again?

- robert

On Sun, 2005-05-01 at 21:53 +0100, robert burrell donkin wrote:
> 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
> 
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://slf4j.org/mailman/listinfo/dev