Justin Erenkrantz wrote:
> On Fri, Nov 14, 2008 at 9:52 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Even when others stepped up to describe
>> how a high degree of parallelism could still be maintained while honoring
>> the API, no effort was invested into making ra_serf do the right thing. And
>
> That certainly doesn't match my recollection of the conversation. The
> only response that I recall that was championed was to disable
> parallelization/async entirely. It should be obvious why I felt that
> was a non-starter...
I pointed you to the editor's provision for so-called "postfix textdeltas"
(but I think you didn't like that the properties couldn't be similarly
handled). Greg Hudson pointed you to ra_svn's pipelining design, which IIUC
is somewhat async though not parallel?
> However, to say that it doesn't work isn't a fair claim. Is it
> optimal? No. But, I can do lots of things to httpd to screw ra_neon
> over too. (I had to add a lot of complexity to support servers that
> had poor Keepalive values.)
That's true. I shouldn't have referred to Neon as the "one that works" --
that was not what I was trying to communicate. I was trying to express only
that Neon seems much faster than Serf in those messed-up server
configurations, and certainly no slower than itself elsewhere, so with Neon
as the baseline, we run the risk of a performance regression in some places.
By have both lines of code, we empower users to get the best deal for their
servers.
OT: I almost hesitate to ask this, but is there value in implementing a
single-main-connection codepath in ra_serf that could be used when it
detects a server configured un-serf-friendly-like? We'd still be able to
drop Neon, but this would offer a best-of-both-worlds approach in a single
library?
>> who routinely writes code against Subversion's APIs, I take API promises and
>> compatibility seriously.
>
> I do too, but even still reading that one obscure comment (ordering
> rule #3) in svn_delta.h (which I probably overlooked at the time), I'm
> still not sure I would have understood what it meant. The breakage
> certainly wasn't intentional on my part - but once it was pointed out,
> I think the constraint doesn't gain us anything and that it comes with
> a substantial penalty.
Yeah, I'm not in a position to speak to the penalties -- there have been
quite a few bits of opinion flying around this list lately about the
pros/cons of one connection versus many. I have no experience in this area,
and therefore no opinion about the best way to go. All I know is what the
API promises me (and others), and that's why issue #2932 was filed.
Now might be a great time to rethink the editor API (it's too much and
too-pervasive code to want to rev it often), so if that's the recommended
solution to these woes, awesome!
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-11-14 16:58:54 CET