On Fri, Jan 24, 2003, [EMAIL PROTECTED] wrote:
> I am not really convinced about the use of fsl. IMHO the fsl approach has
> many more risks and annoyanced than benefits.
>
> - fsl is a library not an asynchronous daemon
That's correct and we've this async issue already on our OSSP l2 (the
underlying library) TODO list. Unfortunately this is not easy too
achieve.
> -- if fsl fails --> the application segfaults
Sure, but the same is theoretically true for
syslog(3), too ;-) Has OSSP fsl already failed for you?
> -- there might be a performance impact (synchronous writing)
Yes, but only if you write without buffering to a local file via OSSP
fsl. You still can program OSSP fsl to perform like syslog(3) and send
the message via UDP syslog protocol to the local or a remote syslogd(8).
So, OSSP fsl in general is not a performance impact, it depends on _HOW_
it is used for logging. The default config for all daemons currently
use buffered logging to a local file and we've not seen any noticeable
performance penalties on our systems.
> -- no support for enterprise typical central logging via the network
This is not correct. OSSP fsl leverages the full OSSP l2 functionality
and with OSSP l2 you can do really all types of logging, including
sending your messages over the network. You even could get real-time
notifications on an IRC channel if you're crazy enough ;-)
> - fsl is a non standard facility
<grin> Sure, everything not covered by POSIX or similar specifications
can be considered non-standard. But the same applies to OpenPKG, it is
fully "non standard". So this issue should be not a problem, shouldn't
it?
> -- fsl requires extra loc for every rpm
"extra loc"? You mean the fsl.<package> file? Yes, but this is harmless
and theoretically could be even avoided by a single "catch-all" OSSP fsl
configuration. We just decided to be more precise and gave every OSSP
fsl based OpenPKG package its own fsl.<package> file.
> It might be worth considering alternative approaches to the sylog issue.
We already had the old "fakesyslog" library and OSSP fsl _IS_ the
considered alternative approach. Because what we need in OpenPKG is the
ability to redirect all syslog(3) logging events in arbitrary ways and
in particular to local logfiles (which in turn is important or you would
be not be able to install multiple OpenPKG instances and this way run
perhaps multiple MTAs on the same machine).
So, we've fully in sync with the opinion that the _implementation_ of
OSSP fsl is still not optimal. But the design in general we nevertheless
consider reasonable for the requirements in OpenPKG. So, IMHO what we've
now have to do is to just improve the implementation of OSSP fsl.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
