Re: IETF meeting comments

Bob Denny wrote:
> 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.

I think the latest Microsoft clients work just fine with a compliant 
WebDAV server, that is, no more problems with the correct date formats 
(in the past it would only work when the (proper) date would come with a 
datatype declaration).

> 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.

Not really. In the meantime, the working group has agreed that "lock 
null" resources are just too complicated to justify them and has settled 
with something cheaper. Hence, if you LOCK an unmapped resource, this is 
equivalent to PUTting an empty resource, then locking it. This should 
make things *much* easier and works fine with the standard clients.

> 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.

That's why we have a mailing list and try to get out updated specs.

> 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.

That's probably correct. In particular, I think having a RFC2518bis with 
locking removed (into a separate spec) may actually help adoption of 
WebDAV. It's important to realize that not to implement WebDAV locks is 
just fine; WebDAV consists of namespace operations (COPY/MOVE, Depth 
operations), metadata (PROPFIND/PROPPATCH) and locks (LOCK/UNLOCK). The 
latter are optional, and many interesting things can be done entirely 
without them.

> 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.

This is probably a good idea. Did you take a look at the "WebDAV book of 
why" (<http://www.webdav.org/papers/#misc>) and Lisa's book 
(<http://www.amazon.com/exec/obidos/tg/detail/-/0130652083/002-9165843-0104803>)?

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 27 July 2004 19:35:45 UTC