RE: Recommendations for integrating WebDAV and other applications

Alan:

I have just finished integrating a (custom modified) open source DAV server
for use with my company's collaborative portal offerings and would like to
offer my experiences and thoughts, as well as pose some additional
questions.

| 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/...

In our implementation, the DAV server is Java servlet-based and to access
content via a web server, the URL would actually include two prefixes--one
for delimiting the root of the portal web-app, and the other representing
the servlet-mapping to the DAV servlet (e.g. http://localhost/portal/dav).
IMO, this only increases the flexibility of the solution, allowing multiple
portal web-apps per machine and/or multiple dav servlet mappings per
web-app.  In other words, I could have any number of portal sites available
from a single host, each with any number of DAV repositories.

BTW, what constitutes a "namespace" in DAV, I'm still not totally clear on
this.  Would the namespace be the URL prefix (before the DAV resource
portion of the URI) without the host (i.e. /portal/dav) or would it be
(/dav) or is it something totally different?

| 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/...

We would handle this by having the root URL be an index page that redirects
appropriately based on user context (including authentication/authorization
credentials, device, language preferences, browser version, etc.).  In
particular, I might be inclined to forward/redirect the "public" request to
"/" to a public collection inside the DAV namespace (proper usage?) that
contained BINDings, which are essentially symbolic links to other DAV
resources that can maintain properties such as access control permissions,
separate from those defined on the target of the link.

| 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 intentionally left up to
| developers?
| Would any clients break if they had to be given http://localhost/webdav/
| instead of http://localhost/?

Don't see a best scenario easily here, but I believe standard J2EE-container
security mappings could easily manage this type of setup, while still
maintaining the flexibility of allowing the situation I described above
(multiple namespaces per web-app, per host) to function.  I even have an
HTTP-based DAV explorer-like interface component that might be mapped to
/portal/davclient, which encapsulates all of the access to the DAV server
and provides the most-appropriate or preferred access interface based on
context.

And I'm sure there are similar ways to accomplish the same thing using other
paradigms besides J2EE...


Thanks,

Jason Coward
Technical Relationship Manager/Developer
Mongoose Technology, Incorporated
jason.coward@mongoosetech.com
http://www.mongoosetech.com

Received on Friday, 29 June 2001 09:30:20 UTC