On Tue, 2005-05-17 at 23:39 -0500, kfogel@collab.net wrote:
> It's hard to bunch multiple requests into one network turnaround if we
> have a separate vtable method for each request. Of course, it would
> be equally hard with the generic RA method described above.
Our RA vtable can be viewed as a set of remote procedure calls. Each
has a name, some inputs, and some outputs. In the more complicated
cases, reporters and editors might be invoked in one direction or the
other, but we also have a bunch of simple request-result calls like
check_path, stat, get_locations, tec.
The problem you are trying to solve here is that an RPC interface,
although programmatically simple to use, requires a network turnaround
for each procedure call. Your proposed solution is to add a new
category of RPCs which can be invoked in bulk, using a more complicated
API and perhaps a more complicated kind of protocol request. My
reaction is:
1. There is no demand for such a facility right now. The constant
term in the number of network turnarounds per large-grain operation
(commit, update, etc.) is not a performance drag, as long as that term
stays reasonably small.
2. If there ever is a demand for such a facility, it may not be
limited to new operations, and certainly may not be limited to
server-to-client configuration queries or to operations which can be
satisfied with hook scripts. What if I have a hundred paths I want to
check using check_path? Right now I have to wait for a network
turnaround between each path.
It is wrong to create a complicated mechanism in anticipation of a
demand that may very well never materialize. (Can anyone name a single
other server configuration query we might want to perform at commit
time?) And we should not let the possibility of this particular demand
prevent us from adding new RA queries, because this nebulous future
requirement may have bearing on queries we already have.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 18 08:36:38 2005