Okay, sounds good to me, I withdraw my uninformed commentary. :-)
Thanks for the explanation!
-K
Greg Stein <gstein@lyra.org> writes:
> > 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