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

CJ Holmes, Julian:

There are various ways to approach this problem. 
Since it is a data modeling problem, the
correct way is to approach it from a data modeling perspective.
We are unlikely to end up with the best data model if
the problem is approached in some other way.

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.

Once there is agreement on this most-basic-point-of-all, 
it becomes appropriate to move forward and address other 
concerns. This basic point must be addressed first, before
anything else.

Alan Babich

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, March 02, 2002 4:22 AM
To: CJ Holmes; w3c-dist-auth@w3.org
Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)


CJ,

I understand your frustration.

However,

so far you have failed to answer the following question:

Are the source and it's output (from an HTTP point of view!) the same
resource? If they aren't, they MUST have different URIs. This is a
fundamental property of URIs and resources that you just can't throw away
because it *seems* to be convenient for you.

If you say they are, you'll have to convince us that the source code (of for
example an ASP page) and it's output are different representations of the
same thing.

For instance, let's take the example of an ASP page that creates the list of
current bug reports for a certain product "test". It's output is identified
by

	http://server/foo/bugs.asp?product=test

It can also be used for other products, so the *different* URI

	http://server/foo/bugs.asp?product=test2

represents a completely different resource which only happens to be produced
by the same script. Finally the script may have a default view (giving a
form), which is identified by:

	http://server/foo/bugs.asp

All these resources are different (and thus have different URIs).

Let's say that http://server/foo/bugs.asp happens to be WebDAV-compliant
resource. When you pass the URL to somebody else, s/he will ultimatively do
a GET against it. What GET does is defined in RFC2616, not in WebDAV. As

	http://server/foo/bugs.asp

identifies the *output* of the script, it cannot be used to identify the
script itself (otherwise, please show us!).

What you *can* do is add a DAV:source property that contains the URI of the
actual script (which will actually send the source text upon GET). Some
examples are:

	http://server/foo/bugs.asp?action=send-the-source

	http://server/foo/?source-of=bugs.asp

	http://server/foo,source/bugs.asp

	http://server/sources/foo/bugs.asp

	http://server:81/foo/bugs.asp

and so on. Note that only some of these formats require a second URL
namespace / virtual host / port.


Finally, please see what the HTTP spec (RFC2616) says in it's first
paragraph about GET:

"9.3 GET

The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI.
If the Request-URI refers to a data-producing process, it is the produced
data which shall be returned as the entity
in the response and not the source text of the process, unless that text
happens to be the output of the process."


Julian


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Saturday, March 02, 2002 3:36 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> >  > Yeah, but it's OUR problem, and not yours.  If our DAV implementation
> >>  is unsatisfactory to our customers then we have to change it.  But
> >>  this would let us (and other implementors) give our customers what
> >>  they want, which is DAV access to their source files with virtually
> >>  no configuration necessary.
> >
> >No configuration is necessary with dav:source other than what was already
> >done to create the dynamic resource.
>
> I've tried to explain the real-world "hassle for no gain for most
> people" situation on this about five times now.  I'm not going to
> repeat it because apparently nobody on this list thinks such issues
> merit much weight.  But I guess what administrators have to do to
> configure their servers or how much we confuse hapless users is
> inconsequential in the face of the prospect of adding a mote of dust
> to the pure model of DAV.
>
> >  > All we need from the protocol group is a sure way to know that a GET
> >>  command originated from a DAV client.  Is that so much to ask?
> >
> >No, the problem is that your question starts off with an awful design
> >decision and expects the WG to validate that through another unnecessary
> >and completely lame hack.
>
> It starts with trying to find a way to accommodate users who don't
> give a darn about using DAV on display resources, and would like to
> use DAV to edit their sources without screwing with the URL.  If it
> was just a minority of users, it wouldn't be an issue.  But it is a
> majority of users and installations, so it is an issue.
>
> Translate exists because it solves this problem by identifying GETs
> >from DAV clients.  If we have to use Translate to give our customers
> what they want, then so be it.  I was just hoping we could get
> something defined by a group of thoughtful people instead of
> something undocumented.
>
>
> cjh
>
> --
>

Received on Saturday, 2 March 2002 16:34:12 UTC