Has any discussion occurred around using a formal WSDL for SVN server
access? Most developer tool kits for Java, .NET, Adobe Flex, PHP, etc ...
have direct support for WSDL access.
-----Original Message-----
From: sussman_at_gmail.com [mailto:sussman_at_gmail.com] On Behalf Of Ben
Collins-Sussman
Sent: Tuesday, September 30, 2008 2:23 PM
To: Subversion Developers
Subject: New HTTP Protocol (was re: svn commit: r33365)
In all seriousness, I really do want to start a design discussion on
the list... but it's much easier to start a discussion when there's a
document for everyone to talk about. That's why I committed the doc
first.
Just as gstein finally stepped up to the plate regarding libsvn_wc --
"enough already, stop the madness", I feel like our continued use of
DeltaV is another madness that needs to be corrected.
Eight years ago, gstein painted a rosy picture of all sorts of DeltaV
clients and servers popping up, and we shared a dream of being at the
forefront of that ecosystem. It turns out that while WebDAV itself
was a success (there's a client built into every OS now), DeltaV never
really caught on. While I think our choice of "apache as server" is
still a huge win in terms of features, we've been paying a continual
price for trying to support DeltaV. Specifically, (1) a huge
performance penalty, and (2) a huge maintenance burden.
If you look at my designdoc, I'm basically suggesting we create a new
HTTP protocol that's entirely specific to subversion. In a nutshell,
it's essentially svnserve's protocol over HTTP. Just as each svn_ra.h
API corresponds to a single svnserve network turnaround, I'm
suggesting we do the same thing over HTTP. For reads, we issue a GET
request; for writes we use a POST request. In both situations, the
exact RA command and parameters embedded directly in the request URI.
For example, this API:
svn_error_t *svn_ra_rev_proplist(ra_session, 23, &props, pool);
Would turn into a request like this:
GET /repos?cmd=rev-proplist&r=23
(Incidentally, this is the way mercurial embeds its own RA API in
HTTP, and it works swimmingly.)
What's the point of doing all this?
1. We get a big speedup. No more crazy turnarounds trying to
'propfind' our way through layers of DeltaV abstractions. Instead, we
can make apache respond nearly as fast as svnserve -- every RA request
is exactly one turnaround. I would expect svnserve and apache to have
the same number of turnarounds, with the same minimal amount of data
per request.
2. We get long-term maintainability. If gstein and I got hit by a
bus, how many people could step in and debug mod_dav_svn right now?
With this new system, we get an HTTP protocol that's just as readable
as svnserve -- one which instantly makes sense to anyone looking at
the network trace, and which is just as easily extended as svnserve.
I know certain folks have put a *lot* of effort into making ra_serf
handle all of the insane edge-cases and quirks of DeltaV -- and I
don't mean to diminish that work. But for the long term, I want to
put my foot down and "stop the madness". If some high-powered admins
out there really need autoversioning, or want to put up a proxy-server
that can handle all serf checkouts under a huge traffic load, or have
transparent write-thru proxying -- then fine, mod_dav_svn can be the
proper tool for that job. It can stick around, along with client
support for 'classic' DeltaV protocol. But for the mainstream users,
teams choosing apache shouldn't have to be jealous of svnserve's speed
and comprehensibility.
My only request is that before jumping in on this discussion, please
spend 3 minutes reading the doc I committed. Among other things, it
explains how I envision interoperability between old/new
clients/servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
---------------------------------------------------------------------
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 03:06:52 CEST