W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2007

Re: Blog comments on <http://tinpixel.com/node/28> -- "Why I don't like WebDAV, part 1"

From: Mike Douglass <douglm@rpi.edu>
Date: Tue, 30 Oct 2007 13:41:11 -0400
Message-ID: <47276CB7.7090109@rpi.edu>
To: Julian Reschke <julian.reschke@gmx.de>
CC: WebDAV <w3c-dist-auth@w3.org>

These are all implementation issues.

I use subversion every day and it's fast and very reliable - 
surprisingly so for a networked protocol.

I also use a Xythos server when I have the time - it's appallingly slow 
but it's neither Xythos nor the protocol - the server is a slow desktop 

Julian Reschke wrote:
> Hi,
> the blog <http://tinpixel.com/node/28> requires a login to comment, so 
> I rather just do it here...:
>> Why I don't like WebDAV, part 1
>> Posted October 23rd, 2007 by chris
>> in
>>     * gripes
>>     * protocols
>>     * software
>>     * technology
>>     * webdav
>> Yesterday and today I spent a lot of time using WebDAV updating one 
>> web site, and creating another, both at hosts which use that protocol 
>> for accessing file directories on hosted sites. It has taken longer 
>> than it should have, possibly caused my Mac OS X 10.4.10 desktop to 
>> crash, and ultimately forced me to use both the shell and FTP to get 
>> permissions set right and the right files in the right places. It 
>> shouldn't be this hard. Part of the blame may lay with Mac OS's 
>> native implementation of WebDAV, but I've not seen any implementation 
>> that is better on the whole.
>> WebDAV comes up short, because:
>>    1. It is not reliable. It frequently leaves files incompletely 
>> transferred, gets hung during transfers, gets permissions wrong, or 
>> issues false alarms.
> That's an implementation problem. I'm not sure what server was 
> involved, but this has nothing to do with the protocol itself.
>>    2. It is slow. Annoying slow.
> No, it's not.
>>    3. It is incomplete. No surprise, being built on top of HTTP, a 
>> protocol never meant for file handling semantics. There's no clean 
>> and reliable way to do stat(2) and chmod(2) functions -- something 
>> pretty much implemented in every file system used on the server side, 
>> and necessary for getting the job done.
> I don't see why PROPFIND wouldn't be sufficient for stat(2), and ACL 
> (RFC3744) wouldn't be sufficient for chmod(2).
>>    4. There are no industrial-grade or polished, complete 
>> implementations. Is there any implementation not based on the Neon 
>> libraries? Not to criticize the authors of Neon; after all, it's a 
>> volunteer open-source project -- but, Neon has not exactly had a lot 
>> of active development and rigorous testing (other than by poor 
>> hapless users).
> Subversion seems to be quite happy with Neon. That being said, there's 
> also serf (<http://code.google.com/p/serf/>) or the Apache httpclient 
> libs.
>>    5. It's obtuse. Did they really have to invent new names for 
>> everything?
> I'm not sure what this is about... Maybe the author would have 
> preferred "STAT" over "PROPFIND"?
>> Some people praise or use WebDAV over FTP, because of FTP's 2 biggest 
>> glaring short-comings -- lack of encryption (a solved problem) and 
>> lack of authentication flexibility (how hard can it be to add that to 
>> an FTP server?). That's hardly a good reason to invent and use a new 
>> protocol which fails to meet the needs in a bunch of other ways, and 
>> is pig slow and inefficient compared to FTP. Why not just improve FTP?
> WebDAV is as fast as FTP, usually being only limited by bandwidth and 
> latency of the link. And of course there are lots of other reasons to 
> like WebDAV, such as that it *is* HTTP -- no new URI needed to edit 
> something that already is on the web.
> Best regards, Julian


Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Received on Tuesday, 30 October 2007 17:39:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:42 UTC