Wed, 19 Dec 2001 11:25:16 -0800
Ka-Ping Yee writes:
> Consider NFS, SMB, CVS, or SQL. Each of these supports some
> notions of remote update, locking, copy/move, and properties.
> Some already support access control and versioning, which DAV
> does not yet support. How is DAV better than just another
> incomplete implementation of one of these?
DAV vs NFS & SMB:
* DAV works better over high-latency links, and hence works better over the
Internet. NFS and SMB are significantly more chatty than DAV, and hence any
additional latency is multiplied several times to accomplish a given logical
* While NFSv4 does have transaction capabilities that would reduce the
latency problem, it comes at an additional implementation and complexity
cost. I don't believe this transaction capability has yet been widely
* DAV operates directly on the URL namespace, whereas SMB and NFS do not
have a similarly uniform namespace.
* DAV is intended to be executed in user space, not kernel space, and hence
does not need to depend on compatibility with the de-facto file i/o
interface standard. This is good, since file i/o does not typically include
notions of properties (the Mac is running away from this as fast as they
DAV/DeltaV vs CVS:
* The DeltaV protocol (recently approved by the IESG, currently awaiting
final processing by the RFC editor), is designed to map to multiple back-end
repositories. The CVS client-server protocol essentially sends CVS command
line invocations over the wire, and hence is heavily ties to the semantics
of CVS. Due to this, several SCM vendors are actively working on adding
DeltaV support, and none are working on adding CVS client/server protocol
support (despite the fact the CVS client-server protocol has been around for
* CVS has several drawbacks, including the inability to version directories
(DeltaV handles this), and poor versioning of binary content (DeltaV handles
this well too). How serious are these drawbacks? Serious enough that the
co-author of "Open Source Development with CVS"
=sr_2_75_1/107-8023658-0930160>, Karl Fogel, has felt enough pain that he is
a key principal in the development of Subversion
<http://subversion.tigris.org/>. Subversion uses DeltaV over the wire.
DAV vs SQL:
* Note really apples to apples comparison, but the short answer is, a
relational database is not the best way to store large chunks of
unstructured data. Most DAV implementations use a database to store
properties, and store the main content (the resource bodies) in files.
Finally, I'll note that DAV ACLs have just passed their final working group
last call, and are expected to be an RFC by March-April 2002.
OK, my turn. Why does crit.org still not support WebDAV for storage of
annotations? The annotations could be stored in DAV properties, and would
have the advantage that you could easily copy and move resources around
while still preserving their annotations. The crit.org page says, "Support
Open Source", yet you're not using a seemingly very appropriate open
protocol in this project.