On Mon, Sep 24, 2001 at 10:48:35AM -0500, kfogel@collab.net wrote:
>...
> Hmmm. I realize that the current state of affairs is just to get the
> network layer up and running, and does not necessarily indicate
> anyone's preferred design.
Correct.
>...
> Currently, we have this:
>
> 1. Client sends a wc summary to server.
>
> 2. Server sends essentially a "skelta" (skeleton tree delta) back,
> saying what needs to be changed, but not including actual diff
> text or fulltexts.
>
> 3. Client uses the list provided in (2) to do a series of GETs.
> Currently, the GETs get fulltexts, not deltas, but this is
> planned to change.
Yes.
> The next level of optimization, along the path of least resistance, is
> to change (3) such that:
>
> 3. Client uses the list provided in (2) to do a series of GETs,
> each GET retrieving a diff (probably svndiff).
Yes.
> This is an improvement, but it's still far from ideal, because it
> involves at least one extra network turnaround. Am I correct in
> assuming that the final goal is:
>
> 1. Client sends a wc summary to server.
>
> 2. Server sends back a tree delta, complete with diff data. The
> diff data is infix, not postfix, so that an interrupted update
> is still useful, instead of being an all-or-nothing affair.
Nope. Never.
The current model with turning around and doing a series of GET calls is the
most optimal way to go. Consider the effects of caching at various points in
the system (when I say "system", I'm referring to client/network/server). A
tree delta with infix text deltas completely blows any chance of caching. It
means that you're going to hit the DB on every update request. If you use
the GET method, then caching proxies can cache the diffs. Heck, even
*Apache* itself can do caching. Under consideration in Apache right now is
how to handle gzip'ing data for delivery over the network. Part of the
discussion is how to cache the output of that zip process, so it doesn't
have to re-zip it on the next request.
[ yes, I know that svndiff may not compress well (we should be able to
disable Apache's compression for svndiff data), but updates can also give
you new files, and compressing that full text is important ]
So... we aren't going to move to infix. We will add wire-level compression
(but that is also dependent upon Neon, IMO; I don't want to decompress
within ra_dav)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:42 2006