Re: Web Browser WEBDAV support

> WEBDAV is trying to solve a different problem: a protocol
> level interface to sufficent capabilities for new versioning-based
> authoring applications to have direct access. Since we're
> looking for interoperability for a new set of functionality
> at the protocol level, we need standards for those new functions
> if we're really going to have interoperability.

As far as I can see, there is nothing within WEBDAV that can't be
done already within the context of the HTTP server infrastructure.
Therefore, I am at a loss as to why it is to anyone's advantage
to produce a protocol level standard to provide the functionality.

As you indicated, there are "dozens" of products that provide
the functionality of remote document editing via the Web.  Shouldn't
we be concerned with producing standards for modularizing these
capabilities and providing standard methods for making requests
in to them while preserving the existing investment in underlying
technology?

I think any standard that simultaneously proposes to extend HTTP,
require a rollout of a whole new generation of Web servers, and
creates a new class of client application for such a narrow
application as WEBDAV will fail as vendors continue to produce
proprietary extensions in the form of server-API plug-ins (CGI, et al)
and Java applets;  customers are not willing to blindly leap to
"standards" if it requires a significant change to the underlying
infrastructure.

In a very practical sense I think extensions to HTTP methods should be
reserved for those things that are absolutely necessary - in other
words, those things that just can't be done any other way.
This could ultimately lead to having zillions of new HTTP method
"standards" not just from WEBDAV but from all sorts of other standards
efforts as well;  some day you might have to go down a checklist of
which HTTP methods your Web vendor supports.  And of course, some
vendors will start to make up their own methods.

It just seems like there is an opportunity here to standardize on
some robust, usable methods within the existing infrastructure and
this talk of extending HTTP to support a whole new range of client
apps and tools is like killing an ant with a sledgehammer.

Some of the early discussion in this group appears to have been
highly influenced by the Web server implementors who may see an
advantage in doing it this way;  I think for this to be a successful
endeavor some of the ideas so far will need to be reevaluated with
the input of other types of vendors as well as potential users.

Jon

Received on Friday, 2 May 1997 09:05:31 UTC