RE: DAV-Enabled field (was RE: A case for GETSRC)

>The most fundamental question from a data modeling perspective
>is the following: "Is the source the same entity as its output?"
>Julian and I agree that it is not. RFC2616 section 9.3 says
>it is not. Julian has provided examples below, including the
>case of multiple outputs from the same source supporting that
>position.

I've given in on the source-vs-display URI.  In fact, I've always 
acknowledged that it is a perfectly good model.  What I'm trying to 
do is allow people who only use DAV for editing sources to not have 
to do extra configurations to make it happen.

All I'm asking for at this point is some way for server implementors 
to know when a GET arrives from a DAV client.  A DAV-Enabled (or 
whatever) field on the requests would do that.  I'm not trying to 
break the model, or add new methods.  I just want to know when a DAV 
client is GETting a resource vs a normal web client.

Why?  Because what most users expect is to be able to edit their 
pages at the same URI.  I realize that doesn't fit your model, but it 
is what most people really want from DAV.

Even assuming we were to implement a way for our DAV to map sources 
onto some user-configurable alternate URI space with a minimal amount 
of configuration, one of the first things people would ask us is why 
they can't use the same URIs for DAV and for their web browser.  And 
they aren't going to understand the data modeling argument.


I think having this field would:

	(a) speed up the adoption of DAV by solving a serious problem

	(b) retain the clarity of the data model and make it clear 
that a good implementation would have separate URI spaces

	(c) ultimately encourage use of DAV:source, since lots of 
people will finally be using DAV and start to understand the 
advantages of source vs display URIs


I realize adding such a field would not contribute materially to the 
data model or the theoretical soundness of the protocol, but it would 
remove a major headache from the configuration and management from 
most DAV servers.

cjh

--

Received on Monday, 4 March 2002 17:14:08 UTC