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

Re: New HTTP Protocol (was re: svn commit: r33365)

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: Thu, 2 Oct 2008 06:54:02 -0500

On Thu, Oct 2, 2008 at 2:04 AM, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:

> Wild-ass suggestion - I know where Greg and I will be between November
> 3 and 7th - *grin* - how about coming down to New Orleans and stopping
> by ApacheCon to go over this?

Justin -- I'm totally aware of the need for (a) cacheability and (b)
allowing pipelining whereever possible. I've been talking with gstein
about this stuff both on this list and in IRC, so I promise I'm not
going to be a religious zealot in terms of mapping RA apis to single
network requests. That's the *general* default pattern, but I think
we'll have lots of exceptions where it makes sense. For example, an
'update' should be requestable either as a single response (with all
filedata), or as a skeletal response, allowing serf to follow up with
pipelined (cacheable) GETs.

Also, I agree that if speed were the *only* issue, we could start
making a bunch of hacks to the existing protocol to get 'most' of the
speedup we want -- make the client start constructing URIs by itself
to eliminate turnarounds, stop using xml, etc. But a large goal here
is to also make things more readable and maintainable for people who
have never seen our HTTP layer before -- it should be as blindingly
obvious as the svnserve protocol, not something steeped in DeltaV
concepts.

But yes, there's actually a chance I may need to be in New Orleans for
a couple of days in early November -- totally unrelated to svn. If
that happens, I'd be thrilled to meet with you guys in person.
Meanwhile, let me keep poking at the designdoc and soliciting
discussion.

P.S. I did some reading on both protocol buffers and thrift -- and
neither technology seems to work as a replacement for our XML trees.
We need to make sure that our big trees (editor-drives) are never held
entirely in memory at once, either when serializing or deserializing
them. Both protobufs and thrift insist on holding the whole 'object'
in memory at once. Urk. Maybe we can just share svnserve's
parser/unparser for lisp-representations of trees. I'm sure it's
still way faster than XML.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 13:54:17 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.