On 11/24/05, Greg Stein <gstein@lyra.org> wrote:
> > Of course, there are certainly other reasons that ra_dav is slow (lets
> > make a million PROPFIND requests before we do anything! ok! how
> > about we base64 encode all binary data so it's bigger than it has to
>
> Note that the base64 encoding is because we embed the content into a
> big-ass XML response. Switching over to the GET form allows us to send
> the content to the client in its original binary encoding.
True, it would be nice to see what kind of effect that would have on
our speed just from improved bandwidth usage.
> What operation are you referring to which does all the PROPFINDs?
Well, it seems like just about all of them do a bunch, but 'svn list'
is perhaps the best example.
> > be! great! etc.) so perhaps it's worth moving towards a custom
> > protocol that uses http, is built with the possibility of being http
> > cache friendly, but doesn't fall victim to the problems we currently
> > have with DAV.
>
> Feel free, but I think there is ample room for improvement by moving
> back towards "plain old HTTP/DAV" than to increase the customization.
> As mentioned before, you could always tunnel the svn protocol, or
> something close to it, over an HTTP pipe. Dunno how cacheable that
> would be; I guess you could always do more protocol design work...
I'm thinking something like the svn protocol, just with the option to
tell the server you'd rather get the file contents/deltas via a
separate GET request, so that the hypothetical http pipelining ra_dav
could take advantage of http caches.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 24 19:32:50 2005