On Fri, Jan 25, 2002 at 10:33:03AM -0600, Eric M. Hopper wrote:
>...
> WebDAV? Why? Seems like adding a useless layer to me. Lets replace
> the very simple xinetd with a much more complex Apache, and add an extra
> superfluous protocol layer as well! OSes that make writing to a socket
> somehow different from doing any other kind of IO deserve to have it be
> complicated to port stuff to them. Luckily, you were farsighted enough
> to make this easy to change if someone gets irritated enough by it.
Here are some of the benefits of our choice of using WebDAV:
* builtin web browsing of the repository. for example, take a look at:
http://svn.collab.net/repos/svn/trunk/HACKING
(that's the HEAD right there; we also have URLs for every previous
revision of every file)
* DAV-based browsing. use Web Folders or WebDrive or somesuch on your
Windows box (or Windows XP's native DAV mounts) to browse the SVN
repository with Windows Explorer. Mac OS X has builtin DAV server
mounting. Nautilus has DAV capabilities. Then you have your Open Source
tools such as cadaver, Goliath, etc.
* existing libraries. I couldn't even begin to count the number of HTTP
tools and libraries available. If we had designed our own protocol, then
we would have /none/ of those benefits. Heck, two HTTP library
implementors (Joe Orton of Neon, and Daniel Stenberg of CURL) are regulars
here. we wouldn't get that benefit. I've used Python's httplib (and a
davlib of my own) to do a lot of testing of our server. No need to go and
roll new protocol libraries.
* existing tools. one word: Ethereal :-) When we capture network traces,
Ethereal already knows about HTTP. It's quite nice, but I know there are
even better ones out there. but we also have other tools like squid and
other (caching) proxies.
* and that point: caching proxy. Subversion will work great with caching
proxies. there is no longer a need for specialized tools like "cvsup".
just drop in a caching proxy, and you've already got your distributed
read-only repository. that european dev team can just drop in the cache
between them and the US server and their checkouts/updates will get cached
for the benefit of the other team members. commits will flow through, back
to the US-based server.
* sophisticated, broad authentication. we don't have to reimplement an
authentication scheme for a new protocol. we can use all of the various
schemes that have been defined for HTTP. ever look at CVS? ever see the "I
Love You" or "I Hate You" lines? :-) that is all part of creating a new
authentication scheme. but we get to use SSL and certificate-based auth if
we want. Kerberos. NTLM. or even just simple Basic or Digest. and our
users can come from text files, database, LDAP, or PAM. we don't have to
reinvent the wheel cuz it is all available for Apache already.
* awesome network server. we don't have to worry about how to portably set
TCP_CORK for optimal network packets. we don't have to worry about when
sendfile() makes sense, or if it is available. we don't have to worry
about dropped client connections, how to best use threads and processes to
scale, request management, monitoring, logging, etc. Apache gives us all
of that and a ton more. I *really* would not want to do that through
xinetd. I mean... setting TCP_CORK on stdout? freaky :-)
* well-defined on-wire compression. we already have on-wire compression,
similar to CVS's "-z#" switch. and we didn't do anything. the client
library and server that we use just support it automatically for us.
* future interoperability with IDEs and other WebDAV/DeltaV clients. as
DeltaV becomes more prevalent, IDEs could very well use it for source code
management, and we'll be right there without needing to write some MS/SCC
library to interface to the tool.
And that is just what I could think of off the top of my head. Give me some
time, and I could probably double the list :-)
Designing new wire protocols for sophisticated applications is a losing
proposition. I might not use HTTP/DAV/DeltaV between my computer and a
remote temperature sensing device, but for a source code management system?
Hell ya. :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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