> -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 30, 2005 7:41 PM > To: Log4J Developers List > Subject: Re: slf4j and log4j ... > > > > 2) There is demonstrated consensus from the slf4j organization. I want > some > > understanding that their (future) release version attains whatever goals > > they have set and that they do not expect it to change significantly in > the > > future. If this was an effort within Apache, trying to achieve a common > > interface/api, I would have the same requirements (though I think it > would > > be easier, quite frankly). I use the word "consensus" because I expect > > there to be a group of developers deciding the slf4j fate. > > Unfortunately, building a community of developers is easier when there > is a released product available! > > But yes I think a release is also a little too early. SLF4J developers > may wish to review the enormous volume of emails re "enterprise logging > for JCL" that occurred on the jakarta-commons-dev list about 3 months > ago. This debate (mostly originating from Richard Sitze) was about > enhancing the JCL API to perform i18n along with other issues. This > discussion is probably equally relevant to the SLF4J API. [NB: no > conclusion was reached during this debate and discussion eventually > trailed off without action].
There is nothing wrong with breaking the slf4j stuff into different "domain" interfaces. If all I want as a developer is simplified, cross-logging framework api and I don't care about the enterprise aspects, why should I be forced to use the most complicated enterprise api? The 1.0 version of slf4j could be the simpler api (modified to accept analysis from the JCL team, whatever comes of that or other considerations). A later 1.X or 2.0 version could include the more complicated enterprise interface definitions (or whatever the slf4j team deems required/worthy). The log4j team could choose to implement that new version or not, but it could still support the 1.0 api. Some industrious soul could still create their own implementation of the updated api based on log4j if they wanted. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
