On Tue, Sep 30, 2008 at 5:22 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> 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.
This sounds pretty great to me.
> 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.
Is there possibility of making a common library that they both can use
for most of the heavy lifting?
> 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.
A little confused by this last sentence. There are three points
included in it. Wouldn't the first one be the only one that required
mod_dav_svn? It seems like this new library could work as well, or
better with the other two.
> 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.
Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
do this too though. As I said, I think this is a great idea and even
overdue.
It seems like if we architected this right, it would not be too hard
for someone to create an IIS add-in that also supported this feature.
Ideally, the real work would be in a reusable library for the Apache
module and maybe even svnserve and an IIS version could be created
that used the same library?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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-01 00:12:53 CEST