Attached is the diff against HEAD as of about an hour ago.
I am all for logging as a plugin, I think. Would this be where you could
have a selection of plugins which may register themselves for various
logging levels to be called as a hook?
# in a plugin:
...
$self->register_logging(LOGINFO, "log_info");
...
sub log_info {
my ($self, $msg) = @_;
syslog(LOG_INFO, $msg);
}
...
---- OR, like a current plugin -----
# in a plugin:
...
$self->register_hook("logging", "mylog");
...
sub mylog {
my ($self, $level, @log) = @_;
my $msg = join(' ', $$, @log);
syslog((($level - 1 < 0) ? 0 : $level -1), $msg);
return DECLINE;
}
...
# and then in lib/Qpsmtpd.pm:
...
sub log {
my ($self, $trace, @log) = @_;
$self->run_hooks("logging", $trace, @log);
}
...
Either way, I like having the flexibility. There is a little chicken/egg
issue though with the second example in that there's no place for connection
logging prior to the plugin getting loaded. If you look at the very bottom
of my patch, you'll see how I cribbed forkserver to get around that. It was
a calculated loss until syslog was set up.
On 11/28/04 4:22 AM, "Matt Sergeant" <[EMAIL PROTECTED]> wrote:
> On 28 Nov 2004, at 05:33, Robert Spier wrote:
>
>>>>> I can pull head, port, test and diff
>>>>> it sooner than later if there's any interest. I know some use
>>>>> multilog, but
>>>>> I've been running with stdout piped to logger until I patched for
>>>>> it.
>>>>
>>>> This wouldn't be a bad thing to have.
>>>
>>> How about logging going through the plugin mechanism? I'd *much*
>>> rather see that than having to custom hack each new logging mechanism
>>> in.
>>
>> I think plugins are a little too heavy for this.
>
> Why? We have config plugins - are they too heavy?
>
>> Log::Dispatch is tailor made for this. (Which I'd prefer to see used
>> instead of hacking syslog support in.)
>
> Yeah, but L::D has a boat load of dependencies (IIRC). Right now
> running qpsmtpd is as easy as untarring the distro and doing ./run -
> I'd rather not break that if we can help it.
>
>
