On Wed, 2004-04-14 at 19:22, Ben Reser wrote:
> a) You're assuming the only protocol we have to support is DAV. This
> isn't the case. We have the svn protocol (svnserve) to support. I'm
> not sure how easy passing along a locale would be to craft onto it
> without running into comptability issues.
FTR, that wouldn't be difficult at all.
But it would probably also be possible to extend the svn_error_t
structure before 2.0, if we don't mind duplicating some information. It
would go something like this:
* Add fields msg_fmt and msg_args to the end of the error structure.
msg_args is an array of string.
* svn_error_createf would format the message into the message field,
and would also quasi-format the message into a format string
containing only "%s" format specifiers and string arguments. (One
gross way to perform this quasi-formatting step would be to plant
distinctive markers around the format specifiers, and then pull the
strings out of the formatted result.)
* Find a way of extending the ra_dav error marshalling syntax so that
we can send the msg_fmt and msg_args data in addition to the regular
data, without angering old clients.
* In ra_svn, transmit the msg_fmt and msg_args fields at the end of
each error tuple.
* Write a simple routine to perform "%s" substitutions on msg_fmt and
msg_args. (We can't use apr_psprintf for this purpose because it
can't take a programmatically-determined list of arguments. Also,
we
need it to be proof against malicious data from the server, such as
an intentionally short argument list.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 15 19:23:43 2004