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

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

From: Greg Stein <gstein_at_gmail.com>
Date: Sun, 23 Jun 2013 22:42:34 -0400

On Sun, Jun 23, 2013 at 7:35 PM, Peter Samuelson <peter_at_p12n.org> wrote:
>
>> If you really want to push, then "proxy-hates-chunks" could work well.
>
> Oh man. Not "proxy-blows-chunks"? (SCNR.)

LOL!

Actually, after an offlist email with Daniel, I would like to "insist"
on just calling it "busted-proxy". We don't need to be fine-grained on
a config option that is only used for edge/broken cases.

Consider the counter-example, where we have three proxy-related
problems. We create *three* configuration options, document all three,
and implement all three across ra_serf. And they are all edge cases.
That is a lot of documentation and work for edge cases. And why do we
need to solve proxy problem #2, and *avoid* hauling in solutions for
#1 and #3? To optimize the user experience in a non-ideal situation?
[by optimizing use of the (busted) proxy]

I believe that the right answer is that we would take all three proxy
issues and lump them all under "busted-proxy". Even if the target
proxy doesn't suffer issue #3, it doesn't really hurt to throw in a
solution for that, even though the user is only experiencing issue #1.

And shoot... let's say that we *do* find a serious issue with a proxy,
which we don't want to haul in when a user is only experiencing
lack-of-chunked-requests. Then we just change busted-proxy from on/off
to on/off/horribly-wrong. Or maybe *that* proxy problem gets its own
config option. Unless/until, then I really think a single catch-all is
the best approach.

To be concrete, we've suggested sending a second OPTIONS request to
detect lack of support for chunked requests. Two years from now, we
discover another proxy problem and instruct the user to turn on
busted-proxy. Is it really a hardship for *that* user to have a second
OPTIONS in their startup logic? Nah.

The user will work to fix the proxy issue, or lobby for its solution.
While that happens, they will suffer a bit of degradation under the
overall "busted-proxy" flag. This isn't an area that we need to
partition and discretely solve. Especially since it "shouldn't" exist
in the first place.

Cheers,
-g
Received on 2013-06-24 04:49:47 CEST

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