15.4 Technology Considerations

Most of the work in writing a custom WebDAV application has really been done already that's the whole point, after all. These are components that already have been written. Open-source or otherwise free components exist for each of these categories:

• WebDAV implementations, either standalone clients or servers or APIs for either

• XML engines to parse and generate XML, and tools to transform and display XML

• Web servers, application servers, and Web security modules

• Script engines for browser scripting

This section provides a little help choosing components and technologies.

15.4.1 Choice of Framework Software

When choosing WebDAV client or server software, consider your functional needs early on. The first question to ask is whether an application or an Application Programming Interface (API) is required. A custom WebDAV application may extend or use an existing WebDAV client or server. Some clients and servers offer extensibility APIs that allow a wide range of changes to be made to the repository or interactions. Other APIs are simply libraries without stand-alone programs. Choosing the right piece of software is especially important in either case (see Table 15-1).

Table 15-1. Feature Considerations

Client	Server
Metadata Considerations
Does the client allow you to view (and edit) the metadata that your application will use? Web Folders and Office 2000 do not.	Does the server allow the quantity of metadata your application will use? If your application relies heavily on metadata retrievals, is it fast? Apache with mod_dav has metadata size and performance limitations unless the metadata store is replaced with a custom storage layer.
Locking Considerations
Does the client reliably lock files it is working on and then release them? This is particularly a concern for drive mapping clients, where users may forget they are working on a shared file. Web Folders attempts to lock files for only two minutes at a time. The server needs to be able to handle this if Web Folders is being used.	Most servers support locking, but does the server guarantee lack of conflicts if you need locking? IIS 5.0 supports resource locking but not collection locking. In addition, IIS 5.0 locking may fail if the data is being accessed via other protocols.
Versioning Considerations
Does the client support versioning? Does it support the packages you need? Most clients do not support versioning yet.	Do you need particular versioning packages? Do you need auto-versioning?
Searching Considerations
Does the client support searching at all? Does it allow searching on custom fields? Can it do a "client-side" search if the server doesn't offer searching? Most clients do not support resource searching yet.	Do you need metadata searching? Do you need the ability to search the body of text-based resources? If so, do you need indexing for faster searches? Apache with mod_dav doesn't support searching, but the open-source mod_dav extension Catacomb may add sufficient search functionality for your application. Searching isn't quite standardized, so consider whether the implementation supports a recent draft of the DASL proposal or has gone a different way entirely.
Access Control
Do you need the client to be able to view and set access control, or is it enough for the server and its administrators to set it?	Do you need the server to support the DAV ACL specification, or is it enough for it to offer custom access control functionality?

15.4.2 Choice of XML Parser

WebDAV implementations are greatly affected by the choice of XML parser because WebDAV uses XML namespaces, and not all XML parsers do namespaces equally well. Microsoft's XML parser (version 4.0 and later) works with COM (Visual Basic and C/C++). IBM and Apache have XML parsers that work with Java. James Clark's "expat" nonvalidating XML parser library for C is recommended for its high performance. This library can be found at sourceforge.net/projects/expat/.

Some parsers do validation, comparing the XML document to a DTD to ensure that the document follows all the rules of the DTD. However, few, if any, WebDAV servers take advantage of validation, because WebDAV request and response bodies may be extended. (Read Appendix 3 of the WebDAV RFC to familiarize yourself with the special requirements of WebDAV.) RFC2518 requires that any element that is unrecognized by the recipient must be ignored along with everything inside it. Thus, the only advantage of doing validation is to reject messages that do not contain required elements in the right places; validation must not reject messages that contain extra elements. The XML DTD in RFC2518 cannot be directly used in validation because it does not show all the places where there may be extra elements.

Many sites are dedicated to XML and you can find many comparisons of XML parsers. This information changes faster than a printed book can reflect. Instead, try PerfectXML.com, O'Reilly XML.com, or devx (www.xml-zone.com) for reviews. The XML pages at the W3C site www.w3.org/XML/) have extensive software listings.

15.4.3 Libraries and APIs

WebDAV APIs exist for several languages and platforms.

Java

IBM Alphaworks hosts the WebSphere DAV for Java API (www.alphaworks.ibm.com/tech/DAV4J/). It's an API designed to simplify client application development, and it supports Java Remote Method Invocation (RMI).

The Jakarta Slide project consists of a number of modules that work with each other over the Internet using WebDAV. The content management system includes a Java API for server-side operations, supporting WebDAV Class 1 and 2 (including locking), access control, versioning, and searching. The client components include HTTP and WebDAV libraries as well as WebDAV-enabled Swing (Java GUI) components.

Xythos WFS includes a Java API for customizing server operations. The entire Web-based GUI included in the product is available as sample code using the API. Functionality exposed through the API includes WebDAV Class 1 and 2, access control, versioning, searching, quota, and tickets.

The Java servlet API can be used to implement a WebDAV server. Although it doesn't natively support WebDAV methods or operations, its HTTP method support (e.g., parsing headers, handling requests and responses) can easily be adapted to handle WebDAV methods. Note that the iPlanet application server blocks WebDAV methods, so it's only possible to use that server if some trick is used to bypass the blocking logic (e.g., by moving the method name to a header).

Python

Both client and server WebDAV libraries exist for Python. The Python davserver is a set of Python classes that implement a WebDAV level 1 server. It was written for groupware software but can be used for general-purpose servers. The documentation is as yet rather light but may improve by its 1.0 release. A Python DAV client interface will be part of Python 2.0 when it ships, as an adjunct to the HTTP classes already present in Python.

There's some argument that Python is the best language to use here if the choice of language is wide open. Three Python WebDAV servers have already been written, including one written as a master's thesis (by Christian Scholtz). In terms of general characteristics, many believe that Python has many features and resources that make it good for all sorts of Web applications. It comes with:

• XML parsers and other XML tools

• URL parsing and construction tools

• SSL support

• A rather capable and customizable HTTP server implementation

Perl

PerlDAV is an HTTP and WebDAV client library. It supports SSL and Digest authentication and all the basic WebDAV methods.

15.4.4 XML Stylesheet Language and Transformations

The eXtensible Stylesheet Language (XSL) is a language for expressing transformations, including stylesheets. The transformation algorithms are built using XSL Transformations, resulting in a document with processable instructions on how to transform one kind of element into another kind of element or text. XML Path Language and XSL Formatting Objects are also part of XSL. These tools help build more powerful transformation algorithms or stylesheets.

In general terms, a stylesheet is a template for transforming data into presentation. Any data that fits the stylesheet's requirements can be handled by that stylesheet. A frequent example is to translate a list of books with information on authors (expressed in XML) into a HTML table displaying those books and authors.

Transformations are even more general than stylesheets. A simple translation could convert an XML document listing each book with its authors to another XML document listing each author with his or her books. In addition to generating HTML and XML, transformations can even convert XML into very dissimilar text formats such as PDF.

Stylesheets may be easier to write in many situations than text manipulation code, and they are certainly more portable.

Displaying PROPFIND Results

Because the results of a PROPFIND request are expressed in a standard XML format, a stylesheet can be used to display the successful PROPFIND results as HTML. This means that "dumb" clients, which have no knowledge of what kind of resource is being viewed or what its properties are, can still do a good display job by downloading the stylesheet that goes along with that resource. The stylesheet for an "appointment" resource in a calendar folder could do the following:

• Transform date/time elements from the transfer format (20010420T10:06:49) to a display format (10:06 a.m, Sunday, April 29, 2001).

• Display the title, location, start time, and end time at the top of the display space, in bold, attention-getting fonts.

• Display the description of the appointment further down in smaller font, with a scroll bar if necessary.

Transforming Incoming Documents

Documents submitted to a repository can be transformed using XSL. This allows old or competing formats to be converted with a minimum of effort. Transforms can even be used to split a single incoming document into multiple documents, to filter out information that was only useful in transit, or to filter out information that for security reasons should not be stored.

15.4.5 XMLHTTP

Internet Explorer 5.0 and later versions of Internet Explorer support XMLHTTP, a component that was designed with WebDAV in mind. For IE, XMLHTTP together with XSLT allow an ordinary browser to be scripted to efficiently browse and interact with a very rich repository. This was used in Exchange 2000 Outlook Web Access, as discussed earlier in this chapter. More information on XMLHTTP, including sample code, is included in Appendix A, Microsoft and Windows Tips.

Note that even though IE is the only browser to support XMLHTTP (or an equivalent tool) at this time, there is no requirement for the server hosting pages for IE to be based on Microsoft technology. Any Web server can host pages including client script using XMLHTTP. A Java-based server may be particularly suited to host XML data, XML stylesheets, and dynamic Web pages (using Java Server Pages) with client script, because so many tools exist for development of XML- and HTTP-based applications in Java [Avedal00].