On Sat, 2005-07-16 at 10:17 -0400, 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
IMHO:
|
********** | **********************
* Client * | * Apache || SVNserve *
********** | **********************
|
Do you want to allow a client be able to add a entry to a repository
server log? That is how I interpreted it.
I feel the logging functions should be for SVNserve right now and then
can be moved to the client.
The two _could_ share common code ( a "framework" ) iff you can abstract
the configuration variables away to another module which should be
different for each "mode".
Allowing a client to write their own entries in the servers log (on
remote machine) seems like a design mistake to me. Couldn't this become
a DOS attack as _anyone_ can write a client to fire log messages at a
repository server.
I might have misinterpreted the comment though, I've been swimming
trying to wrap my head around this entire thread/proposal.
> 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.
Why would the client log this? It seems you think they should - other
than the fact client logging would be nice. The server process should
be logging these bad URL's. Correct?
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
21:29:31 up 31 min, 2 users, load average: 0.22, 0.13, 0.10
Received on Mon Jul 18 04:01:55 2005