On Jul 16, 2005, at 9:17 AM, John Szakmeister wrote:
>
> Sure there is. Having the log baton separated from the repository
> baton means
> that you can potentially use logging for other purposes. For example,
> clients could use it for their own debugging purposes (i.e., it
> might be
> easier to get a "traceback" to help track down bugs), or we could
> provide a
> general logfile via /etc/subversion for logging events that don't
> have a
> repository (for instance, someone is repeatedly trying to access a
> repository
> that doesn't exist, or is trying to determine the name of existing
> repositories). The latter method means you need to have a
> repository baton,
> which a client doesn't really access directly, and isn't useful
> when trying
> to log access attempts on non-existent repositories.
>
> In our environment, we're very concerned about logging and audit
> trails. In
> fact, it's a requirement placed on us by the Government. Access
> attempts are
> important in determining whether someone is trying to gain
> unauthorized
> access to material. Fortunately, we get this now via Apache2's
> access/error
> logging. I'd like to switch us to svnserve once the path
> authorization,
> SASL, and SSL stuff makes it in, but we also need the ability to see
> unauthorized access attempts before making that switch.
I don't think we necessarily have contradictory goals here, I think
we're just thinking at different levels.
It sounds like you're advocating a completely generic system for any
process or library to write data to a logfile, anywhere, anytime.
I'm advocating a system designed around a particular use-case: most
logging is related to a repository, so write an API tailored to that
problem.
I don't think these are contradictory goals. For example, we could
implement your generic "logger" object, have it output to an
svn_stream_t, and make it available to all libraries/processes in
libsvn_subr. Meanwhile, my repos-centric logging API could use
"logger" objects under the hood. (In other words, an svn_repos_t
would contain private logger objects for each of its errorlog and
accesslog.) Both goals are now achieved.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 16 16:51:42 2005