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

Why not WebDAV (was Re: first impressions...)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-01-26 17:09:34 CET

So, Greg Stein assembled an impressive list of advantages for WebDAV
and DeltaV, which one might think would turn anyone into a true
believer. I'd like to explain why I'm not, although I obviously don't
expect to change the direction of the Subversion project at this late
date. (And, actually, I wouldn't change the direction all that
dramatically even if I were Lord God King of Subversion and it were
still early in the game. I'll get to that at the end.)

I also don't particularly want to make this into a huge thread which
degenerates into quibbling over small details; I just want to show how
someone can be faced with such a powerful-seeming argument and still
lean the other way.

Going over the advantages:

  * builtin web browsing of the repository
  * DAV-based browsing

These qualify as "cute, but not part of our charter." Built-in
NFS-based browsing would also be neat, and would integrate with many
more operating systems, but no one would seriously suggest it. If
someone came to this list and really wanted to do NFS-based browsing
they would rightly be told to write a gateway, not to make it a core
part of our architecture.

  * existing libraries

The problem here is that we're bringing in a very large amount of
existing code and it's only doing a relatively small amount of work
for us--basically amounting to a bit of framing and representation.
We still have to write mod_dav_svn.

And in addition to the complexity of using a large amount of code to
do a small amount of work (which a good engineer should understand is
bad even if we didn't have to write that code), we also have to puzzle
out how to make our semantics match with DeltaV's--something we
haven't yet managed to do in all cases. So I think it comes to more
work, not less.

  * existing tools [for monitoring network traffic]

They can decode our framing, but they can't penetrate the meaning of
our operations. And in a text-based protocol, the framing is pretty
transparent to the human listener anyway. So, not too impressive.

  * caching proxy

This is half-assed. As has been pointed out several times before, an
HTTP caching proxy will only be able to cache operations like "update
from rev X to rev Y of file Z". Since there are n^2 different updates
for each file of n revisions, an HTTP cache might provide very little
advantage if access patterns are not tightly synchronized.

On the other hand, a Subversion-specific cache could keep track of the
actual repository and do a 100%-effective job in less space. So
unless it turns out that an HTTP cache does a very good job due to
locality of common access patterns (which I doubt), someone will wind
up writing a Subversion cache anyway.

  * sophisticated, broad authentication

I find the HTTP-based authentication options somewhat lacking. TLS,
CRAM-MD5 and BASIC don't really cover the range of options a site
might be interested in.

If I were designing a protocol, I would use SASL. There are libraries
for it (and every byte of code in those libraries does something we
want) and it is more expansive.

  * awesome network server

Illusory, I think. Subversion is never going to make use of
sendfile(), at least not with its current filesystem architecture, and
setting TCP_CORK is of highly limited usefulness. It has no advantage
if you do your own buffering, unless you're going to use sendfile()
and thus can't do your own buffering; even then, we're talking about a
difference of one packet. Like sendfile itself(), setting TCP_CORK is
more important for winning benchmark pissing matches with Microsoft
than for solving real performance problems.

And once again, we get to use a very large amount of code (Apache) to
do a very small amount of our job--just inetd's job plus a little bit
of HTTP framing.

  * well-defined on-wire compression

This advantage is on target, but is pretty easily replicated in a new
protocol.

  * future interoperability with IDEs and other WebDAV/DeltaV clients

This is the kicker, if it ever materializes (which isn't necessarily
the case; the world is littered with promises of future
interoperability which never came to be). If, twelve months down the
road, Microsoft Visual Studio--or whatever development environment 80%
of serious Windows developers use at that time--supports DeltaV and
has never heard of CVS or Subversion, then any open source version
control system will have a much better chance of penetrating Windows
shops if it implements DAV.

Here is how I would handle this situation: design our primary network
protocol to be targeted and implementable in a small amount of total
code (a SASL library and maybe a thousand or so more lines of code
than we have in mod_dav_svn, at a guess). WebDAV would become a
secondary network protocol, and we might not even implement it until
we find a real, widely used version-control-enabled IDE out there
which supports DeltaV. Only people concerned with those particular
clients would need to use Apache, and we would never need to implement
WebDAV on the client side (so we would never need neon).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006

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.