Our WebDAV love affair?

A while ago my company met WebDAV, we spied it across a crowded room and knew instantly that it was the technology that we want to be with, forever. Thus followed a whirlwind romance and a very quick marriage.

Now we have been together for 2 years and the honeymoon is definitely over, but unfortunately we've had kids and now divorce seems as problematic as trying to work around our issues. We have a mistress on the side, SOAP Web Services, to provide what is missing from our relationship with WebDAV. What is to be done.

At this point I should make sure that you understand that I am in no way having a go at the people who have worked tirelessly to bring the WebDAV family of specifications to the point that they are at now. The work they have done is great, on a standard that doesn't have anywhere near the support that it should and one that has been implemented in a bad way many times.

The IETF WebDAV group began officially on March 20th 1997, there is now the core WebDAV specification, DeltaV versioning extensions specification, Ordered Collections, Access Control Extensions and the in progress DASL Searching specification. Pulled together these form, on the surface at least, a well rounded set of specifications, however 2 years is a long time to get to know something.

We started working with WebDAV because our company had instituted research days, once a month, for all the developers. We each got to try out new and interesting things as long as they were something to do with what we do, which is build online information systems with a heavy focus on use of metadata. One of our developers was exploring the idea of layer new interfaces onto the CMS aspect of our server software. He got FTP working, then Telnet and finally tried out WebDAV.

It was a good fit, we have resources to which we allow people to attach metadata, which is exactly what WebDAV gives you. Straight away we ran into 2 problems, the first was that there is no way in WebDAV to supply to the client application the definitions for each of the properties. Secondly there is no agreed way to pass around multiple values for a property. A property can simply contain <xs:any/> element.

So we designed extensions to WebDAV for this, which worked well, and completed the implementation of the core specification. We skirted around having to implement the immature versioning specification by simplifying the view over our versioning and relating these through metadata. We used the HTML <ol/> and <li/> constructs for the multiple values, which was a work around proposed by the Dublin Core group. This was the basis for our first release.

Since then we have gone on to expand on the metadata definitions extension, we've move the multiple values constructs over to using the SOAP specification array concepts and implemented DeltaV versioning, Ordered Collections and DASL searching.

To a degree all of this has worked. I say to a degree because there are problems with these specifications. You need only look at the changes in the recent revision to the core specification to begin to understand how much needed clarification. There is not enough integration across the specifications, our implementation of the DeltaV specification had to skirt the lines across 2 of the different implementations flavours to be able to lay on top of our versioning system, which isn't that unusual.

There are missed opportunities, such as the lack of a definition of what a Principal is. In the LOCK specification the lock owner is a URI to information about this user. In the versioning specification there is also talk about users and URIs to information about them and finally in the Access control extension there are Principals, with WebDAV paths to them. However these Principals, and the WebDAV path/URIs, are in no way specified as being the same as the other user URIs. We have assumed this, and gained so much more out of it.

User handling is perhaps the area of greatest weakness, there are others mostly stemming from the specifications not quite explaining things enough (could of course just be me being thick). But yes, user handling is the worst, again not really WebDAV's fault, mostly from the awful way in which HTTP authentication works. We have ended up plugging these gaps with Web Services.

So I guess my advice is that WebDAV worked well for us, it got us up and running fairly quickly without having to design a comms protocol ourselves, but we have spent a long time tailoring and extending it to meet our exact needs, generic though it is you just cannot use it as the sole protocol for an entire system even though it might look like you can at first.

WebDAV and us will not be getting a divorce anytime soon, but I will definitely think twice the next time my eyes meet those of such a lovely technology across a crowded room!