- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Fri, 29 Jun 2001 09:44:05 +1000
- To: WebDAV <w3c-dist-auth@w3.org>
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 19:44:38 UTC