On Wed, Jul 10, 2013 at 4:20 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>...
> Taking the "the client MAY ..." literally, we're compliant ... but
> there's something to be said about about following the spirit of the
> spec as well as the letter.
You're the one debating compliance.
> I wouldn't really mind breaking peoples' setups if Subversion had issued
> chunked requests before,
There's *always* a first time. We gotta start some time.
> or if we'd announced well in advance that not
> supporting chunked requests is going to break something -- the way we
> did, for example, warn about the server-side effects of HTTPv2 and its
> multiple connections and many more requests. But it did not cross our minds.
Same with the level of bustitude out there on the Internet. We had no
way to measure it until now. Breakage happens. Obviously, we try to
avoid it. *shrug*
> We'd always sold ra_serf as "ra_neon but better". So now we're faced
> with a regression that we can fix in one of two ways: lay the burden on
> each and every user that uses a site that's behind a certain kind of
> compliant proxy, or lay it on site administrators. I maintain that the
> latter is the better solution; even if it means making opening the
> session less than optimal until some 1.8.2/serf-1.4.0 combination gets
> released.
I already said that I could agree its a regression.
Is the community going to be just as up-in-arms about the "svn status
--xml" regression? Is that one just as important to fix? How do you
measure user impact and importance? Does this proxy problem rise to
the same level?
IOW, while I may agree with "regression", I'm not sure that we should
impact 99+% in order to deal with it. I'm not sure it is a reasonable
tradeoff.
The "auto" suggestion is good, but it *will* impact 1.8.x users. We
can solve most of that in the 1.9.x timeframe. But that still leaves
1.8.x out in the cold. CMike spent a lot of time on HTTPv2 reducing
the number of (synchronous) requests to the server. I hate to see us
retreating from his work, to try and solve something with a miniscule
impact, which can be solved with a client knob or a proxy upgrade. We
can use the knob/upgrade strategy for 1.8.x and handle it better in
1.9.x (and possibly deprecate it, if our detection/solution gets good
enough).
So that's my issue right now: is knob/upgrade good enough for 1.8.x,
with better answers in the 1.9.x timeframe?
Cheers,
-g
Received on 2013-07-10 16:45:57 CEST