batch-mode fixes [was: [PATCH] fix read-batch SEGFAULT]

[Wayne Davison]

On Sat, May 15, 2004 at 11:53:05AM -0400, Chris Shoemaker wrote:
> Not only does the client pass the "--write-batch=pfx" argument to the
> server, but it's actually the server calling all the batch write
> routines.

This isn't client/server differentiated, the current code appears to
have been written to make the sender write out the batch info, so in
this case it's just that the server happens to be the sender.  I think
in the original design it was imagined that people would always push
data when they wrote out batch files (but we'd have to ask the designer
about that).

So, it certainly makes more sense to me to have all the info be
generated on the client side.  Unforunately, that sounds like the code
would need to be further munged so that it outputs either from the
sender or the receiver, depending on who is the client.  Ick.

Another thing I ran into the other day was that the --read-batch code
appears to not support a remote destination.  I tried to run a test to
a host:some/path destination, and it complained that it couldn't write a
local file of that name.  I don't know if this is a design constraint or
a bug (because I haven't looked into it).

> Oh, and AFAICS, the unfortunate way to handle legacy broken servers is
> for the client to suppress passing the --write-batch arg, otherwise
> they'll still hang, even with new clients.

There might be other reprocussions to that, but not sending the option
is certainly right choice if the client becomes the only one dealing
with it.  Since the batch processing has always been marked as
experimental (and since it appears that not many people use it), it
would be fine to make a newer version of the code simply refuse to
interoperate with any older versions when --write-batch was specified.

..wayne..