RE: Recommendations for integrating WebDAV and other applications

I can see why you would want the authoring location to be different
from the released location, but just for interests sake, can you
explain why you would separate the webdav root from the dms root?

In any case, I know of no client that requires WebDAV to be enabled
at "/". 

Cheers,
Geoff

-----Original Message-----
From: Alan Kent [mailto:ajk@mds.rmit.edu.au]
Sent: Thursday, June 28, 2001 7:44 PM
To: WebDAV
Subject: Recommendations for integrating WebDAV and other applications


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

    http://localhost/webdav/...
    http://localhost/dms/...
    http://localhost/public/...

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

Alan

Received on Thursday, 28 June 2001 23:32:54 UTC