On Tue, Sep 30, 2008 at 2:22 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> Would turn into a request like this:
>
> GET /repos?cmd=rev-proplist&r=23
I'm repeating a bit what Greg already commented in the docs, but yuck.
This is a *very* ugly way to do this. Plus, you are killing off any
way of doing caching by using query args. Any solution that we do
should be very simple and scale with good HTTP proxy caches, IMO.
A lot of the extra round-trips with DeltaV come from property-hell -
splitting things up into multiple requests is a *good* thing - big,
giant API calls are a disaster and should be avoided. Thinking that
more 'REPORT' calls is the answer seems like we're going down the
wrong path. Fine-grained and quick APIs should be our desire, IMO.
But, the issue with properties is that it introduces a linear, ordered
dependency between requests - this means that the GET for the data and
the PROPFIND for the metadata have a relationship. If we could
somehow better combine that into one request/response cycle, we'd
simplify a *lot* of code.
Also, using XML as a transport mechanism is just plain lame - as Greg
said in the protocol docs, switching to protocol buffers or something
like that would be a *huge* performance win. ra_serf pretty much only
uses XML for meta-data, but it's still a PITA.
By and large, my experience with ra_serf is that a lot of the
intrinsic current performance bottlenecks is waiting for disk I/O due
to crappiness inherent in libsvn_wc. Fixing up libsvn_wc to have a
much higher throughput should enable us to see where things could be
improved at the protocol level. So, it'll be a bit chicken and egg
here with the wc work too.
The one killer feature I want to add to ra_serf is commit
parallelization - this is something that svnserve can't do (it does
just a tiny bit of commit pipelining), but I think we can come up with
a clever way of doing it. And, honestly, DeltaV isn't *too* bad when
it comes to this, so it's probably already somewhat doable, but
there's some nasty request dependency issues.
> My only request is that before jumping in on this discussion, please
> spend 3 minutes reading the doc I committed. Among other things, it
> explains how I envision interoperability between old/new
> clients/servers.
Wild-ass suggestion - I know where Greg and I will be between November
3 and 7th - *grin* - how about coming down to New Orleans and stopping
by ApacheCon to go over this? I think a few hours or even a day
face-to-face would really help here and I think we could walk away
with a pretty finished protocol stack design. From my ra_serf
background, I know where the particular pain points are. So, I'd
really like to be able to contribute here... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 09:04:38 CEST