Olin, we're trying to do something essentially very simple here, and
No, you're not. The syslog facility actually has a fair number of knobs
& dials, unfortunately. And I don't think my API in general use will
be very complex. It will be basically an application-top-level form like
;; Mail daemon top level
(with-syslog-channel (syslog-channel "mail" syslog-class/daemon)
(initialise-spool-directory)
(set! smtp-thread (spawn-thread smtp-server-loop))
(admin-repl admin-port))
and then sprinkled throughout the app occurrences of things like
(syslog-write syslog-level/critical "Spool volume out of space.")
or
(syslog-format syslog-level/warning "Possible spam attempt host=~s IP=~x"
host ip-address))
That seems pretty straightforward.
If you *must* handle syslog connections implicitly (which I think is a
bad idea because of the connection information stored in it), then
I'm not sure I understand what you mean by the above. Can you explain? My API
is a lot like the R5RS I/O system -- explicit ports, but a dynamically-scoped
way to establish a default for the basic operations (input, output, logging).
In the syslog case, this is useful for general-purpose libraries that do
logging of unusual situations. They simply log to the default syslog channel.
Higher-level code globally establishes the default syslog channel's name &
class for the entire service/application.
let's eliminate the idea of a syslog channel entirely and simply
provide
(syslog-write level msg [name class option])
So any piece of code that wants to log a message is responsible
for determining the name & facility class of the top-level application?
And the only way for an application to choose a policy on something
like "include the pid in the logging" is to get *every* use of syslog-write
in that application and *all* the libraries that it uses to specify that option
in the call? That's your idea of simple?
If we do it your way, then syslog state, like the application's name
and facility class, has to be passed around and down into the bowels of the
system. *That* is complexity, to me. These bits of information are not
properly part of the logging operation -- the logging operation's relevant
parameters are simply the message and its severity level. That is a
proper separation of concerns.
Some of the complexity of my API comes from the fact that it tries to export
as much control of the underlying system as possible -- and that underlying
system has a lot of knobs. Such as the NWAIT facility, which in fact is
necessary for apps that need to control the order in which they allocate file
descriptors. If we only wanted to give partial support, we could remove the
SYSLOG-FORCE-CONNECTION procedure.
I'm willing to consider an alternative, but I'd like to see a complete
proposal. Can you do one? If you *do* choose to have a "syslog channel" data
type, then bear in mind that all data types should support equality, hashing &
a type predicate.
-Olin
|