Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2005-08-22 12:01:53


Darryl Green wrote:

> Darryl Green <darryl.green <at> aanet.com.au> writes:
>
>
>>I think what is needed is a set of connections (logs connect to
>>appenders/modifiers) ordered by the log name which may include wildcards. Log
>>name (segments) containing wildcards should be ordered before exact names so
>>the more specific rules override the less specific ones.
>>
>
>
> I'm putting together an alternate manager to implement something like the above.
>
> The semantics will be that you specify logging rules like:
>
> // create/register (but don't connect to any logs) an appender
> log_appender("display") = write_to_cout;
> log_appender("bazfile") = write_to_file("baz.log");
>
> manipulate_logs("foo.bar.*")
> .connect_appender("display");
>
> manipulate_logs("foo.bar.baz")
> .disconnect_appender("display")
> .connect_appender("bazfile")
>
> // one can delete the actual appender
> // which will disconnect it first!
> log_appender("display").erase();
>
> The connecting/disconnecting of appenders maintains a (per appender) set of
> rules for matching logs. The size of the rule set is bounded (assuming the set
> of log names is) by removing redundant rules whenever a modification to the
> rule set is made. The rules are applied in the order they are specified.
>

This does indeed look easier. I want to update the log manager to allow
for this, but I don't think I'll have the time to do it, before the
formal review (30 Sept).

> Clearly this means changing manipulate_logs, and changing the manager
> concept/interface. I'm finding it hard to see how a really "alternate" manager
> could be written given the rather restrictive set of required interfaces. I
> think manipulate_logs() should simply provide access to completely manager
> defined functionality.
>
> I also find the manipulation of logs by specifying the pattern to match a
> number of logs, then applying a number of appenders to them to be less than
> appealing, I think the "inverse" interface should also be provided ie.
>
> appender("display")
> .connect("foo.bar.*")
> .disconnect("foo.bar.baz");
> appender("bazfile")
> .connect("foo.bar.baz");
>
> Would have the same result as the manipulate_logs lines above.
>

Yup, this makes sense as well.

Best,
John

-- 
John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter)
-- http://www.torjo.com/cb/ - Click, Build, Run!

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk