Ben,
In my experience, what makes a network protocol small and fast is:
1) maximize bytes per request
2) minimize connections per "session"
3) minimize bytes per request [not so critical on Internet (vs LAN) due to
higher end to end latencies]
The existing RA api is easily expressed in WSDL notation, and a lot of dev
tool kits will auto-gen an RPC layer with marshalling which can talk to the
remote WSDL.
-----Original Message-----
From: sussman_at_gmail.com [mailto:sussman_at_gmail.com] On Behalf Of Ben
Collins-Sussman
Sent: Wednesday, October 01, 2008 6:43 PM
To: Paul Charlton
Cc: Subversion Developers
Subject: Re: New HTTP Protocol (was re: svn commit: r33365)
No discussion has occurred. However, just having looked up WSDL in
wikipedia, the concept somewhat horrifies me. Can you tell us why
we'd be interested?
The whole point of this exercise is to develop a small, fast protocol
that directly aligns with svn's already-abstracted network API. The
whole reason the existing protocol is a semi-fiasco is because we were
trying to wedge ourselves into an existing committee-designed spec,
for the sake of interoperability. The chances of getting me to
repeat this mistake are vanishingly small. :-)
On Wed, Oct 1, 2008 at 8:06 PM, Paul Charlton <techguru_at_byiq.com> wrote:
> 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 05:21:10 CEST