On 7/16/05, Ben Collins-Sussman <email@example.com> wrote:
> How is that different than my proposal, whereby the "svn_repos_t"
> object contains all the information to output to the log? I see no
> difference between
> svn_log_error(logobject, level, "message")
> svn_log_error(reposobject, level, "message")
There is a difference in function names.
I think that if you do plan on using a repository specific object as a
parameter in the function call, that you also rename the function to be
"repos" specific, such as
svn_repos_log_error(reposobject, level, "message")
so that the generic svn_log_error function can still exist. Perhaps this was
implicit to some but it should be stated.
On the same note, I strongly support a standard svn_log_* set of functions
that define our core logging APIs. Other module specific functions such as
those in svn_repos, etc. can then simply wrap the main svn_log_* APIs as was
suggested. Several people have alluded to this and Ben has directly stated
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.
- Brian Holmes
Received on Wed Jul 20 04:06:14 2005