[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1502401 - in /subversion/branches/tristate-chunked-request/subversion: include/svn_config.h libsvn_ra_serf/serf.c libsvn_ra_serf/util.c libsvn_subr/config_file.c

From: Ben Reser <ben_at_reser.org>
Date: Thu, 11 Jul 2013 23:17:06 -0700

On Thu, Jul 11, 2013 at 6:42 PM, Greg Stein <gstein_at_gmail.com> wrote:
> Ugh. Why the rename? I spent a bunch of effort bringing the name in
> line with dev@ thinking. This option primarily controls if/when we
> detect for chunked request capability on the connection.

I appreciate your effort and I think the name you went with is ideal
for the boolean value as implemented on trunk. I'll add that I chose
the name before the tristate option was proposed.

I think it's much clearer to explain that the tristate option controls
chunking in request bodies.

Using the http-detect-chunking option name as a tristate with the yes
setting like so:
    http-detect-chunking = yes

Does not make sense. When set to yes we do no detection. We simply
use chunking.

On the other hand setting it to no:
    http-detect-chunking = no

This time it means what it looks like it means, nope we don't detect chunking.

Another reason I prefer the tristate is that it's much easier to
explain. With the boolean we have to try to explain that no means we
just use chunking without bothering to check. We could also have made
no use Content-Length (not that I think we would). But that's not
obvious to a user unless they read documentation.

Whereas the tristate with the name http-chunked-requests is simply
obvious to anyone that reads it.
Received on 2013-07-12 08:17:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.