Subject: RE: WebDAV and Dynamic Content

From: "Tapas Nayak (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 16:39:48 -0800

> 
> 
> Allowing dynamic resource to access resources using the file system
> 
> Most dynamic resources, i.e., servlets, Java Server Pages, 
> Active Server
> Pages, server-side scripting in HTML, CGI-BIN applications, 
> etc. that are
> invoked by a Web server assume Web resources managed by the server are
> stored in the file system, often at specific locations 
> relative to their
> own file system path. This is very unfortunate coupling between the
> server-side extensions, and the Web server implementation, but it is
> standard practice. For many WebDAV servers, and almost 
> certainly versioning
> WebDAV servers, the resources are not stored in the file 
> system, but rather
> are stored in some private repository. For the authoring 
> environment, this
> is no problem because the authoring client just does GETs and PUTs and
> isn't aware of the server's implementation. However, any 
> dynamic content
> processed by the Web server is free to open files on the server as it
> wishes, and if those files are Web resources authored through 
> WebDAV, they
> might not be visible to the dynamic resource and its runtime 
> environment.
> Ideally, the dynamic resource would reference other resources 
> through a URL
> so it could access them through WebDAV with versioning 
> support and proper
> access controls. But in cases where they just open files, we 
> have to have
> some other solution.
> 

Why do we have to have another way for an application which wants to open
files? 
The application either knows that the resource it is trying to access is a
file and 
that is why it is opening a file or it knows that it is a URL and then would
access
WebDAV to access the resource. Having a file system interface is good if
one is available but one cannot ensure that for all WebDAV servers. If
uniformity is  
the concern here then why not expose file systems as  WebDAV instead of 
exposing WebDAV as file system? 

> 1. Require the user to publish from the WebDAV store to the 
> server runtime.
> + it works
> - introduces redundancy with associated system resource 
> consumption and
> update anomalies.
> - requires a separate publish step for every update before it can be
> tested. Likely to cause lots of bugs
> 
> 2. Mirror the resources in the file system.
> + makes them accessible to dynamic resources
> - introduces redundancy with associated system resource 
> consumption and
> update anomalies.
> - what version of a versioned resource would be mirrored? 
> Some published
> workspace?
> - requires users to do a publish step to control when the 
> server cache is
> updated or requires servers to keep them up to date.
> 
> 3. Build a file system device driver on top of WebDAV so that 
> applications
> that access the file system will transparently access WebDAV 
> resources.
> + eliminates the redundancy
> + eliminates the publish step
> - has performance implications
> - introduces OS dependencies, there's no standard file system 
> access API.
> - file system APIs may not be capable of specifying enough 
> information or
> parameters to support versioning, properties, locking, etc.
> 
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 20 Nov 1999 12:56:29 -0500

From: "Tapas Nayak (Exchange)" <[email-masked]>

   > Allowing dynamic resource to access resources using the file system:
   > file system.
   > 2. Automatically mirror the resources in the file system.
   > 3. Build a file system device driver on top of WebDAV.

   Why do we have to have another way for an application which wants to
   open files?   The application either knows that the resource it is
   trying to access is a file and that is why it is opening a file or it
   knows that it is a URL and then would access WebDAV to access the
   resource. Having a file system interface is good if one is available
   but one cannot ensure that for all WebDAV servers. If uniformity is
   the concern here then why not expose file systems as WebDAV instead of
   exposing WebDAV as file system?

Jim is concerned about the case where an application (i.e. the one
producing the dynamic content) only knows about files (not resources
and URL's).  The web server invokes the application to produce the
dynamic content, but the application will be looking into the file
system to find its input data.  He's looking for standardizing a way
for a client to tell the server to instantiate a set of resources
into the file system so that they are accessible to the file-based
tool.

This feels to me like something that is outside of the scope of an
HTTP protocol, since this is so application implementation
dependent.  In particular, it depends both on the file system mappings
that are expected by the applications, and on how resources are
instantiated in the file system.

So if we do decide to formalize authoring of resources with dynamic
content, I'm more inclined to do so in a pure resource context, and
not try to fold in file-based behavior.

Cheers,
Geoff

-- 
Geoffrey M. Clemm
Chief Engineer, Configuration Management Business Unit
Rational Software Corporation
(781) 676-2684   [email-masked]   http://www.rational.com