[slf4j-user] AVSL

[Brian Clapper]

[Forwarding to slf4j-user, at Ceki's request. This is my response to a private
message he sent me. I will also forward a second response. -bmc]

Ceki Gülcü wrote:
> Hello Brian,

Hi, Ceki,

> I just came across AVSL and wanted to add it to the list of SLF4J
> implementations on the SLF4J web-site. It seems pretty obvious that AVSL
> is a native implementation of SLF4J. Would you concur?

I'm not so sure it is.

It provides a built-in SLF4J adapter, but it's written in Scala, so the
native interface is deliberately Scala-friendly (using Scala's call-by-name
capability to delay evaluation of arguments until after the level check).
The SLF4J adapter sits on top of the Scala API, to make the Scala API
compliant with SLF4J and (more) usable from Java.

So, it's native, in the sense that there's a built-in adapter. But it's not
native, in that there is, actually, an adapter layer.

SLF4J's docs clearly state that there's no overhead with Logback's native
implementation of SLF4J. By contrast, there is going to be some slight
overhead in AVSL, because of the adapter layer.

Whether that fits your definition of "native SLF4J implementation" or not
is somewhat of an open question.

> By the way, I would really like to make logback more scala-friendly in
> particular with respect to configuration. Would you be interested in
> contributing?

Sure.

In general, I dislike XML configurations. I think XML is a fine way to
represent data. I think it's a lousy format to force people to edit for
configuration purposes. To that end, I tend to avoid it for my own tools'
configurations.

For AVSL, I use a Scala configuration parsing API that mimics INI- or
Python-style configuration files and supports variable substitution
(including Java System.properties and environment substitution), include
files, etc.

I also have an older, but perfectly good, Java implementation of a similar
configuration file format. I rewrote it in Scala, largely as an exercise,
when I was coming up to speed on Scala. But I still use the Java version in
some of my Java tools (including my "curn" RSS reader). It's in my Java
utility library, which is here:

    http://www.clapper.org/software/java/util/

Class docs for the configuration class are here:

http://www.clapper.org/software/java/util/javadocs/util/api/org/clapper/util/config/Configuration.html

The library is BSD-licensed, so it's compatible with GPL and Apache licenses.

Something like that might be a good start. Being INI-like, it's not going
to support XML-style deep nesting. But I'm not 100% convinced that deep
nesting is necessary for most configurations. Readability and simplicity,
for me, are bigger wins.

Anyway, let me know what I can do to help.
-- 
-Brian

Brian Clapper, http://www.clapper.org/bmc/