Now that I have made significant progress in my WebDAV server API implementation, I can post some details.
My goal is to create an API that faithfully implements RFC2518. This RFC outlines the Http/1.1 Extensions that constitute the WebDAV protocol. There are two levels: Level 1, general WebDAV support, and Level 2, locking support. I plan on supporting both levels, but for the 0.xx release will release with Level 1 support only.
I have designed the API so any developer who knows how to code with a .Net language can use the API. Zero knowledge of WebDAV is required. To use the API, a developer would need to:
1) Reference the API assembly from her/his class project.
2) Provide an implementation of abstract classes WebDAVCollection and WebDAVItem. Basically, you have to map your data store collections and items so that when the API requests a collection or an item, it gets one.
3) Provide an implementation of abstract WebDAVAuthentication class.
To put it in use, you have to:
1) Configure IIS to support file extension .davx and have it respond to all verbs (the extension is irrelevant; if you want, you can have it be .foobar, as long as it responds to all verbs).
2) Add a line similar to the following in your web.config:
<add verb="*" path="MyFiles.davx" type="MyCompany.WebDAV, MyCompany.WebDAV" />
3) Create a file with the name used in #2 (i.e. MyFiles.davx). This file can be empty.
With this in place, Windows or Mac clients can natively map a drive letter using http://yourserver/MyFiles.davx as the path. Alternately, they can directly open a resource as a file from applications such as Word, Excel, HomeSite etc.
I have designed the API so each unique data store type on the server, would have an end-point ({something}.davx) and a line in the web.config.
For example, a handler such as DotNetNukeHTML.davx could be placed in the root of a DotNetNuke portal. A user on a Windows or Mac platform could then map a drive letter using http://yourserver/DotNetNukeHTML.davx/NNN where NNN is the DotNetNuke Portal ID. The user would then see a folder structure where each folder corresponds to a DotNetNuke tab. Within each folder are files corresponding to DotNetNuke module instances. Initially I plan on supporting only the HTML and NukeHTML modules so you would only see files for each instance of these modules. You could then open any of the files using Word, HomeSite or any other HTML Editor and edit the file and save it back. Of course, you can also create a new file which will result in a new module instance being added to the page.
This will basically eliminate the need to use a browser-based editor to create/modify portal content. Just use any rich Windows or Mac editors at your disposal.
This is one example. Using the API, you could also allow full file management on the web server, view a mailbox as a collection of EML files, open up a database table in Excel, there is really no limit to the possibilities. As long as you can figure out a way to present your data (any format) as a data stream that represents the file content expected by a WebDAV-enabled desktop app, you can enable native WebDAV access to your app.
Here's an illustration that gives an overview of how things will work:
