> -----Original Message-----
> From: justin.erenkrantz_at_gmail.com [mailto:justin.erenkrantz_at_gmail.com]
> On Behalf Of Justin Erenkrantz
> Sent: donderdag 2 oktober 2008 9:04
> To: Ben Collins-Sussman
> Cc: Subversion Developers
> Subject: Re: New HTTP Protocol (was re: svn commit: r33365)
>
> 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.
Why would using query args kill proxies?
Any proxy that follows the HTTP RFCs uses the proxy headers to determine
what should and what shouldn't be cached.
The '?' has nothing to do with that.
I know the proxy I used in the late 1990s did some trickery on query
strings, but any HTTP 1.0/1.1 compliant proxy server doesn't handle query
strings that way.
We should just make sure we try to create the parameters always in the same
order as the ordering of the query parameters /does/ matter for caching.
Bert
> 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
---------------------------------------------------------------------
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 10:40:40 CEST