Hi,
>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.
I'm not try to say it either way. ..or any way. I'm hoping that
this potential ability would help to justify the inclusion of this
feature/option in the protocol. More below.
>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.
If the application can be built to be "logging aware", then I would
agree with you. Those applications will probably not show up for some
time. (And I suspect that a lot of though will go into them before they
are implemented. Would the application signal to the daemon that it
has a message but not give it to the daemon until a channel is open from
the daemon to the server? I see lots-o-risk there. Would it give the
message to the daemon but also keep a copy until the daemon signalled
back that it had been delivered? Lots-o-risk there as well. ;-)
In the "logging ambivalent" applications of today, it should be
left up to syslogd to take some appropriate action. It may be that
syslogd can be configured to send event messages to a 'backup' server
if the primary does not verify delivery after some time period. It
may be that it just stacks them up for later delivery and attempts to
send pages to a human. While I consider it to be dangerous, it may
also be an option to allow the syslogd to stop an application. In
this, I am thinking of a firewall that may be required to stop
activities if it cannot verifiably log events.
Thanks,
Chris
