Re: Clarification (fwd)

Forwarded message:
From futrelle Thu May  1 18:26:43 1997
Subject: Re: Clarification
To: jradoff@novalink.com (Jon Radoff)
Date: Thu, 1 May 1997 18:26:43 -0500 (CDT)
In-Reply-To: <33694332.3E0D@novalink.com> from "Jon Radoff" at May 1, 97 06:28:18 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Content-Length: 1958      


> One area I'd like some clarification on (unfortunately I got into
> WEBDAV a little late) is where the protocol is "positioned."  The
> IETF description of the WG talks about developing new HTTP methods,
> etc.
> 
> A concern I would have would be relying on Web server vendors to
> provide the necessary capabilities "soon";  it should be possible to
> implement the necessary protocols through (at a minimum) CGI programs
> that could become extensions of the Web server.  That way we
> effectively support the entire legacy infrastructure.  The existing
> infrastructure of e-mail, Web browser and Web server products
> should be capable of supporting the aims of WEBDAV by encapsulating
> requests within multipart/form-data requests on the "input" side
> and the current Web server infrastructure on the output side.  I'd
> be concerned that extensions to the HTTP header would backfire and
> would grant license to the big players in the server arena (Microsoft
> and Netscape) to dominate the WEBDAV applications market.

In my opinion, CGI is a poor framework for meeting WebDAV's
requirements. NCSA is considering developing a WebDAV-compliant server
which would be released under our free-for-noncommercial-use licensing
terms. And other noncommercial efforts are likely too; luckily, server
development is not a closed shop.

On the other hand, your concern makes sense, and creates the
undesirable situation that people are doing state management within
their CGI subsystems which is redudant with, parallel to, and not
cleanly interoprable with their server's own management of state.
This is a waste of effort, since the more elaborate these systems
become the more they resemble servers and the less sense it makes to
talk to them through forms rather than an adequately flexible
protocol.

-- 
Joe Futrelle
HTTP Server Development, Joule/Hacksaw Group
National Center for Supercomputing Applications
futrelle@ncsa.uiuc.edu
(217) 265-0296


-- 
Joe Futrelle
HTTP Server Development, Joule/Hacksaw Group
National Center for Supercomputing Applications
futrelle@ncsa.uiuc.edu
(217) 265-0296

Received on Thursday, 1 May 1997 19:27:55 UTC