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

Mike Douglass <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <[email protected]>
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 
machine

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                           [email protected]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.