From: jeffz_2002@...
Date: 2007-01-05T10:00:16+09:00
Subject: Re: Who's maintaining log4r?

Thanks for all, folks.

My changes are proceeding apace, though I've not forked a new project
yet.  I'll try finding Leon's email using the method above.  Also,
another developer has also sent me some code he's worked on which I'll
be reviewing, and I'll be sending him mine when I get the tests passing
again (yet another massive change put in place) ... so there are
interested devs out there!

I'd be interested to hear what people feel are preconditions for a new
log4r.  My guesses are:
1. Backwards API compatability for Log4r configs done via XML or YAML,
though some of the semantics may differ (e.g., the RootLogger may log
as well)
2. Same speed as original, or better.
3. Anything that worked before (including ROMP, email outputters, etc)
should still work - though not necessarily in the alpha release

As I mentioned way back in post #2, my current implementation will
likely break any direct calls to Logger.new( ... ) in client code.  My
reason for this is, as suggested in Eric Evans's Domain Driven Design,
clients should probably not directly call constructors ... this ties
clients too closely to implementation, and in the case of Log4r makes
some of the design difficult (tight coupling, global state, singletons,
etc, all the stuff that's really hard to unit test).  Like Log4J, my
implementation does support Logger.getLogger( 'name' ), though it's
written using the index operator Logger[ 'name' ].

But, this is just my stuff, and I'll be sharing this and *hopefully*
combining it with the work of the other developer -- unless his is way
better!

Thanks again,

Jeff