Re: IETF meeting comments

Julian, et al. --

After a 2 year absence from working on DAV, I re-activated my project (a
DAV server-side package) and was quickly overwhelmed with more "gotchas".
The biggest one was an attempt to LOCK a non-existent file by Dreamweaver.

I know you all have put forth a big effort to get DAV into shape to support
it's mission, and it appears that you're about to release the definitive
spec to follow RFC2518.

But as an outsider trying to implement a server, I have once again given
up. The Microsoft "extensions" and quirks (still out there en masse), their
inability to use ISO dates, and the usage patterns that come from the many
DAV clients out there are really too broad-scoped to conceive when
designing a server.

When faced with LOCK on a non-existent resource, my design collapsed. I had
built the DAV server to use the NTFS file attributes (a separate place to
store info related to the main data in a file) so I could support moving
files around on the server machine with the local shell, and have the extra
DAV attributes and locks info move with the files and directories. The
operation of locking a non-existent file invalidates this approach, and
thus my entire design. It appears that a separate parallel universe like
mod-dav is required.

This was not at all obvious in RFC2518. And the "issues" lists are so full
of internals info and wording negotiations that guys like me give up trying
to mine useful implementation tips out of them too.

I know of several people who gave up on client side implementations of
WebDAV as well. Managing locks seems to be the land mine that ends
projects. Personally, I think it got beyond the 90/10 realm, and became
overly complex (hence your approach of dealing with it in a separate
document :-))). I doubt that most of the clients out there need/use but a
small part of the locking features.

Anyway, one thing I might suggest for the working group dinner at IETF is
to set aside some time to discuss how to lower the risks for implementation
of DAV clients and servers by people not actively participating in the WG.
Perhaps a survey of your members on the most common implementation issues,
and things that you probably won't think of when designing from the RFCs. A
"DAV Developer's Guide" (not related to Apache or mod-dav) would be a
wonderful addition to the documentation.

Respectfully,

  Bob Denny
  Mesa, AZ

Received on Tuesday, 27 July 2004 19:22:26 UTC