Heh! Wow, save that post for the next time this question comes up.
-K
Greg Stein <gstein@lyra.org> writes:
> 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
---------------------------------------------------------------------
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