[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 9 Jul 2013 11:19:41 -0700

On 07/09/2013 10:33 AM, Ben Reser wrote:
> So we had a conversation on IRC this morning about solutions.
>
> This is what several of us seemed to agree was a reasonable compromise:
>
> Have a tri-state option called http-chunked-requests. It would have
> three states:
> auto = Run the extra OPTIONS request and detect if chunked requests is
> supported or not.
> yes = Assume that HTTP/1.1 servers have chunked requests support (our
> 1.8.0 default behavior) and always use it against HTTP/1.1 servers.
> no = Never use chunked requests.
>
> With the default being auto.
>
> This provides us a lot of flexibility in handling this. With a
> tri-state we can reasonably change the default behavior if the proxy
> environment changes or we find the auto detection to be too costly in
> the wild. If we find a better way of automatically handling this we
> can change what auto does.
>
> This avoids the need for users to set an option in order to
> interoperate, but users that want maximum performance can set it to
> yes (assuming they don't have such a proxy in line).
>
> Thoughts?

First, I appreciate the time and attention that is being invested into a
workable solution here that recognizes the real challenges of pleasing
our humongous user base. We've outgrown simple "our way or the highway"
dismissals, IMO.

Secondly, I think the tristate option is the best suggestion I've seen
to date, both in terms of coverage and future flexibility (if needed).
Received on 2013-07-09 20:20:14 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.