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

I have CC'd Chris as he was the original author of the flame against
Webdav.  I must say I agree with Mike and Julian that the problem is NOT
the protocol, it is rather the implementation OF the protocol that leads
to user dissatisfaction.  It is unfortunate that Webdav takes a beating
when really its really the implementations that have lead to SLOW BUGGY
software (and since much of this is actually done at the device driver
level, this software is quite complex).

Let's go through the gripes in more detail:

1)  Leaving files half written.  Xythos actually will catch the fact
that a file is not completely written on the SERVER and erase partial
files.  I also know of FTP servers that will have half written files if
the connection is canceled.  The Xythos Drive (a webdav client used by
Xythos, SAP, Oracle, others) will actually try to resubmit items that
were cancelled in order to make sure its cache is consistent with the
server.  Again a client could be written to do the minimal work and
minimal error checking, but again this is not a problem with the
protocol, but rather the software you chose to use.
    Permissions wrong and bad error messages.  Again a problem with your
client.  As Julian mentioned, there is a protocol that allows a user to
set ACLs on a Webdav Server.  In fact both the Xythos client and Server
implement this protocol allowing users to "chmod," with MORE control
than unix, files and directories on the server.

2)  It's Slow.  Yes I agree the default apple client is slow.  For every
write to the server it makes over 6 round trips for an operation that
could take 1.  Again, bad client.  The Xythos client will simply PUT
files across to the server and interpret error responses to give the
user a great experience when working with files.  In Xythos 7.0 we have
a new upload widget that uses Webdav to upload files on the server and
its actually FASTER than any other uploading system I have seen.  Webdav
simply places the bytes over a HTTP request after a small header.  The
bottleneck for transferring bytes is the network.  I have actually seen
Xythos work FASTER than CIFS, NFS and other protocols.  Of course it
depends on what you are doing, but at the end of the day, Webdav simply
is putting bytes across a wire. 

3)  No stat/chmod.  Julian answered this correctly with PROPFIND and
ACL.  Both of which are fully supported in Webdav client/server combos
such as Xythos, SAP, Oracle, etc. 

4)  Ummm Xythos, SAP, Oracle, others

5)  Naming. No comment.

At the end of the day, Webdav is FAR FAR more functional that FTP.  It
includes things like Versioning, Meta-data, Searching, ACLs, etc.  It is
not simply trying to be a file system replacement, but rather a protocol
for authoring and versioning on the Web.  It is unfortunate that many of
the implementations are half-baked.  This has lead many people to bad
mouth the protocol, when really they should be asking their software
providers about their implementations.  I constantly have customers who
talk about the need for Basic Document Services in a WebService
environment.  Guess what, Webdav is a perfect open standard way of
accomplishing 95% of their needs.

We could of course take a few years to wrap Webdav in SOAP, REST or
something else to pick up a few buzzwords, but that just seems more
painful.  There are problems with all Open Standards.  I have a few
issues with Webdav, but can we please place the blame for Webdav failing
where it belongs.

Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
On Behalf Of Mike Douglass
Sent: Tuesday, October 30, 2007 10:41 AM
To: Julian Reschke
Cc: WebDAV
Subject: Re: Blog comments on <http://tinpixel.com/node/28> -- "Why I
don't like WebDAV, part 1"


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                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Received on Tuesday, 30 October 2007 20:43:50 UTC