

Recommendations for integrating WebDAV and other applications

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Fri, 29 Jun 2001 09:44:05 +1000
Message-ID: <20010629094405.A18194@io.mds.rmit.edu.au>
I was after any recommendations or experience others have had of the
best way to integrate WebDAV into an application. In particular, we
want to ship a demo application with three distinct functionalities
in the one web server:

* WebDAV interface to a file system of documents that can be edited
* Web based workflow interface for document management (users log on)
* Public anonymous web interface to released documents

I am thinking at present that the paths in the WebDAV folder are not
going to be related to the paths in the public interface. The folder
paths can be set up by users to whatever structure they want.
The final public application paths are determined by the application
logic. So URIs for WebDAV and for the public web interface are not
going to be the same.

One way to avoid collisions with URLs is to prefix the three different
areas with a name


The public access URL is not very nice though (people want to just go
to http://localhost/), so the URI for / might relocate the user down
into /public/...

The real question for this list is, is there any reason against requiring
client applications to use a base URI of http://localhost/webdav/
instead of http://localhost/ ? Are there any clients that assume
WebDAV folders always start from /? Does it create any bad semantics
starting from /webdav?

The other logical alternative strategy I can see is to mount WebDAV from
http://localhost/ and have hidden URIs of /public and /dms where a
GET request on / relocates the user to /public/...  DMS users can just
be told to start at /dms in order to bring up the DMS interface.

Is there any *best* thing to do? Or is intensionally left up to developers?
Would any clients break if they had to be given http://localhost/webdav/
instead of http://localhost/?

Thanks as always

Received on Thursday, 28 June 2001 19:44:38 GMT
