On Wed Oct 27 05:07 1999 +1000, Darren Reed wrote:
> In some email I received from Mark D. Roth, sie wrote:
> [...]
> > Please correct me if I'm misinterpretting you, but you seem to be
> > saying that the verifyable delivery option should be a configurable
> > parameter at the daemon level. However, it needs to be selectable at
> > the API level because the user process will need the ability to select
> > verifyable delivery before the message even gets to the local syslogd.
>
> Why ? To me, every message that is sent by the local process to the local
> syslogd is sent with the expectation that it will be delivered and received.
I'm not sure that I'm explaining this correctly, so let me back up a
few steps.
The purpose of verifyable delivery is to allow a user process to
determine whether a message submission succeeds, so that it can
perform some alternate action if it fails. To accomplish verifyable
delivery, the receiver must send an ACK once it writes the message to
non-volatile storage. This method works fine when transferring
messages from one syslogd to another, which means that the process
submitting the message can assume that the message will be delivered
once it hits the queue of the first syslogd.
The problem is that a chain is only as strong as its weakest link. If
the process has no way to determine whether the initial syslogd has
received and stored the message, the verifyable delivery flag doesn't
accomplish anything. Also, the messages for which verifyable delivery
is appropriate don't fit neatly into a single category ("facility") or
priority, so there's no decent way for syslogd to determine when to
use it if it's not selectable by the submitting process.
> > Also, just on general principles, I think that the application code is
> > in the best position to determine which behavior makes sense, because
> > the system or network administrator isn't usually familiar with all
> > the intricacies of the code.
>
> So let me get this straight. The administrator configures which messages
> he wants to log but he doesn't configure which of those he wants to ensure
> are logged ?
Actually, this can be configured, but it must be done on a
per-application basis. Just like you can currently tell many
applications which facility to log to, you'll be able to tell them
whether certain messages should be logged with verifyable delivery,
and what actions to take if the delivery fails (e.g., write a local
logfile directly).
Does this make more sense?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
