RE: WebDAV and Dynamic Content

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

Received on Friday, 19 November 1999 19:39:56 UTC