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
shortcut.
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
ra_serf.
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.
Thanks,
-g
Received on 2012-05-19 21:58:54 CEST