[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [DISCUSS] delete ra_neon

From: Greg Stein <gstein_at_gmail.com>
Date: Sat, 19 May 2012 15:58:22 -0400

On Sat, May 19, 2012 at 3:28 PM, Bert Huijben <bert_at_vmoo.com> wrote:
> The biggest benefit of gstein's approach would be that it works even
> for very old servers. A very strong argument if serf would be the new
> default.
> The only other valid option would be to implement the fetch-all, like
> Ivan suggested. That would also perform well on current servers.
> We can't assume users have 1.8 servers the day 1.8 is released :(
> And if we could, we could assume editor v2.

Right. This is why I suggested that we work on Depth:1 directory
PROPFINDs instead of Mike's patch. It will be compatible with older
servers, as Bert says (all the way back to 1.0). And as Justin said:
the property data has to travel across the wire, so whether that is
within a PROPFIND response body, or inside a giant REPORT... it
doesn't really matter. The only *potential* concern is whether the
HTTP request/response overhead is significant.

Now... I don't know who thought a patch existed. I merely stated that
I wanted to do it, and opened an issue about it (see issue tracker).
It would reduce both CPU and traffic.

Regarding synchronous vs async: the commit process *should* be
pipelining its requests. The fact that it doesn't is just a coding

One day in the future, I'd like an FS backend that will allow multiple
connections for commit, but that'll take a while. It will be possible
with ra_serf when that happens. Another option would be for the FS to
advertise whether it can take certain parallel operations: BDB can do
this; FSFS cannot. The client could then improve its operation.

There may be other opportunities for async operation (replay? merge
stuff?). I've been busy cleaning up ra_serf to make it easier to add
Ev2 support. Not really adjust its wire operation.

Anyway... ra_serf enables us to do things that ra_neon never will.
That is why I believe we should jettison ra_neon and just go with

So far, beyond Philip's concern about traffic/CPU tradeoff, and a
couple open issues... I think we're in good shape to pull the lever.

If I've missed some concerns, then please let me know.

Received on 2012-05-19 21:58:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.