Re: Starting work on UGLI

Is it OK if we move this conversation to [email protected]? Having 
a thread spread over 5 lists is not very practical.

At 05:31 PM 6/7/2004, Niclas Hedhman wrote:
>On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
>
> > Given the lessons learned from past experience, in particular wrt
> > extreme simplicity and generality, it is expected that UGLI will be
> > quickly adopted by many developers.
>
>Ceki has previously asked about the so called "No Logging" strategy, which 
>can
>be found on the Avalon Wiki site;
>http://wiki.apache.org/avalon/AvalonNoLogging
>
>"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
>the table around, saying 'The component can express itself in this way. Who
>is interested?"
>
>Now, this solves some issues but raises some new ones;
>
>1. Each object that wants to 'express itself', needs to fire events 
>instead of
>calling the logger methods. Effectively the same thing, except there may be
>many listeners, and the 'expression' is done from the object's PoV and not
>the logging system's.
>
>2. The 'Logger' somehow need to be registered as a listener to the object
>instance. For IoC frameworks that is already in place, but in many POJO
>scenarios, support for 'discovery' has to be made available.
>
>3. The Logging framework do exist, and has a good purpose, and that means 
>that
>an adapter is required between the object's so called Monitor and the logging
>framework. The custom monitor, which defines the 'expression' end's up being
>responsible to tie this expressiveness into one or more interested parties.
>
>
>It could look something like;
>
>
>            |     Custom                 +------------------
>            |     Monitor concern        |  Logging concern
>+--------+ |  +---------+   +---------+ |  +-----------+
>| User   |-|->| Custom  |-->| Log     |-|->| Logger    |
>| Object | |  | Monitor |   | Adapter | |  | Framework |
>+--------+ |  +---------+   +---------+ |  +-----------+
>            |     |    |                 |
>            |     |    |                 +------------------
>            |     |    |
>            |     |    |                 +----------------
>            |     |    |                 | Performance concern
>            |     |    |     +---------+ |  +-------------+
>  User      |     |    +---->| Perform |-|->| Performance |
>  concern   |     |          | Adapter | |  | Monitor     |
>            |     |          +---------+ |  +-------------+
>            |     |                      |
>            |     |                      +----------------
>            |     |
>            |     |                      +----------------
>            |     |                      | Fault concern
>            |     |          +---------+ |  +---------+
>            |     +--------->| Fault   |-|->| Fault   |
>            |                | Adapter |-|->| Monitor |
>            |                +---------+ |  +---------+
>            |                            |
>            |                            +-------------
>
>The examples of other Monitors are hypothetical, just to show some
>'reasonable' use-cases.
>
>What I am trying to show is that the "Logging Concern" is somewhat 
>intersected
>with other monitoring concerns, and that there is a 'space' between the
>"Logging Concern" and the "User Concern". (We at Avalon are
>Concern-Separation-fanatics!)
>
>The challenge now would be;
>
>1. Convince everyone here (first) that this is a useful pattern.
>2. Figure out how the "Monitor Concern" is managed.
>3. Create necessary 'ease-of-use' support for the average user.
>4. Establish an exchange of re-usable Monitors.
>5. Implement it all.
>
>Does anything of the above make any sense to anyone ??
>
>
>Cheers
>Niclas
>--
>    +------//-------------------+
>   / http://www.bali.ac        /
>  / http://niclas.hedhman.org /
>+------//-------------------+

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp