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

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 2 Mar 2002 10:56:22 -0500

Any analogy with POST is not very compelling.
POST started with vaguely defined semantics, and got vaguer.
GET has always had reasonably well defined semantics,
i.e. return the content of the resource identified by the specified URL.

Cheers,
Geoff

-----Original Message-----
From: Matthieu Chevrier [mailto:[email-masked]]
Sent: Friday, March 01, 2002 8:59 PM
To: [email-masked]
Subject: Re: DAV-Enabled field (was RE: A case for GETSRC)

>> 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?
> 
> To be honest: yes.
> 
> GET is GET. It doesn't matter what client it comes from. You shouldn't try
> to change that.
> 

apart if your company's name is Microsoft, right? Because that's precisely
what they did with 'Translate'.

It seems like we are pretty much done with this thread. Just want to add one
little thing : in the SOAP specifications, POST requests MUST have a
SoapAction field. It is not specified what this field should contain, just
that it has to be there. And noone complained that it's breaking the holy
POST.

Soap is of course a completely different protocol compared to DAV, but it's
still interesting I believe to think about why the spec writers made this
choice (or shall I say a lame hack Roy?)

Regards,

   Matthieu.

---

From: "Babich, Alan" <[email-masked]>
Date: Sat, 2 Mar 2002 13:33:40 -0800

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:[email-masked]]
Sent: Saturday, March 02, 2002 4:22 AM
To: CJ Holmes; [email-masked]
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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of CJ Holmes
> Sent: Saturday, March 02, 2002 3:36 AM
> To: [email-masked]
> >  > 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.
>
> >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
>
> --
>

---

From: "Jason Crawford" <[email-masked]>
Date: Mon, 4 Mar 2002 23:59:16 -0500

Eric,
  Nice post.

> It's not clear to me that the generated output from GET on executables
> actually is a different resource.  First of all, it doesn't make sense to
> think of it as having properties separate from that of the script.  I
doubt
> if anyone actually doing the URL space mapping proposed would keep around
a
> set of dead properties for the generated output, but the case becomes
> clearer when looking at the live properties.

I think you're right that a lot of those properties have limited value for
a dynamic resource.  Sometimes they are hard to implement efficiently.
Sometimes the correct value for the server to return for a property might
be ambiguous.
   OTOH... for the underlying source resource, these properties are
probably useful, very clearly defined and easy for the server to return.
That seems to be a good reason to keep the source resource seperate from
the complexity and ambiguity of the dynamic resource.

This is just a response to the first part of your note.   It doesn't
respond to the second part of your note about MOVE which requires more
thought.

Again... thanks for your thoughtful note.

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: CJ Holmes <[email-masked]>
Date: Tue, 5 Mar 2002 10:04:21 -0800

><<
>              (2) "Once the software is written, the dual-URI space is both
>superior and cost-free."  It is confusing to users when they
>configure their DAV client software, and providing support is
>expensive.
>>>
>I don't think anyone went so far as to say it's "cost-free".

Ok, I exaggerated.  But I think the point is still a good one.  Even 
if the implementation is cheap, support can still be very expensive. 
Hence the need for a single URI space from the user's point of view.

><<
>Put yourself in the shoes of the administrator of a University's
>faculty web pages server trying to provide DAV access to their pages.
>Let's say there are about 1200 faculty at your school, and only 1/4
>of them have web pages but only update them a couple times a year.
>That's about 300 phone calls and emails you are going to get twice a
>year asking why they can't get the SSI version of the such-and-such
>page or why they can't "log in with Dreamweaver" to their web page.
>(Reminder: these people are too "smart" to RTFM.)
>
>With this crowd, it would be way easier to just serve the source to
>DAV clients (subject to the proper authentication of course) and
>avoid a lot of these support incidents.  None of them care about
>using DAV on display documents at all.
>>>
>Right... it's probably no worse than the current situation with FTP,
>but if you can improve on the current situation , it can create new
>opportunities.  In this case it would save money for the support
>staff at the university.

Right.  Only DAV is already much better than FTP even without 
DAV:source.  You have arbitrary properties (which many users find 
useful over time) and Locking.  I'm a big fan of locks.

>People have pointed out that the mapping from display URI to
>source URI can be any number of functions.  This has been
>viewed as a feature because it allows the server implementer
>to use whatever mapping makes most sense to him. But that flexibility
>causes complications for a UI that wants to simulate a single URI
>space.

Not just complications in the UI, but also complications for the 
server administrator and for plug-ins trying to stay out of each 
others' way, and configuring security realms that are DAV-specific 
and largely duplications/variations of permissions elsewhere in the 
URI space.

A lot of our customers are beginning web masters.  They want a 
product the works easily "out-of-the-box" and is easy to support. 
They also want something that will grow with them.  Hence our desire 
to provide a simple default configuration (DAV-as-file-system with no 
funny business with the URI space) AND the opportunities for a "real" 
configuration that uses DAV:source and maps two spaces together, etc..

>The client UI doesn't know enough to easily figure out what
>the mapping function is so it can have trouble supporting a MOVE
>operation that looks like a MOVE in a single URI space.  (At
>least that's my current understanding.  I haven't
>thought about Eric's posting long enough to be sure.)

I think it can just ask about the source URI of the destination 
(unless that destination doesn't exist - then what?)

>I'm wondering now if the DAV:source property definition can be
>constrained so that a client can trivially know how the two
>namespaces map to each other so that it can know how to do a
>MOVE in the output URI space and simulate a single URI space.

That's an interesting idea.

cjh

--

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 6 Mar 2002 17:07:07 -0500

It sounds like we have come to an agreement on the benefits of
having a separate URL, and on the benefits of having additional
methods/headers that allow you to use the same URL.

The problem with defining/allowing both techniques, is that some
servers will end up only doing one or the other, and some clients
will end up only doing one or the other.  That means clients
will only interoperate in this regard wrt to servers that do it
"the same way".  And for clients/servers that care about interoperation,
they have to do both, adding to the complexity of those interoperable
clients/servers (and interoperable clients/servers are the ones we
want to encourage/support).

This is a tradeoff decision where reasonable people can disagree,
but for me, the cost to interoperability of "allowing both" outweighs
the benefits of having a "simpler" alternative way of achieving the
same effect of DAV:source.

Cheers,
Geoff

-----Original Message-----
From: CJ Holmes [mailto:[email-masked]]

DASL makes things more interesting because it allows for searching on 
properties.  You might have content with properties that need to be 
searchable, generated by sources with a very different set of 
properties.  (eg: a single source document that generates several 
display documents with searchable properties of different values.) 
Since in this case you _want_ different properties between 
source/display views you get a real benefit from splitting them into 
separate resources with separate URIs.

I confess to not having read the spec, but it sounds like ACL is 
interesting because you could allow the NaturalSciences department 
(as an example) to restrict GET, HEAD, and POST operations in some 
display spaces and assign authoring/editing rights internally in some 
other spaces.  In short, it might allow  for a very author-driven 
security system instead of an administrator-driven one (without 
resorting to editing .htaccess files).  Still, if you had a way to 
differentiate between GET and GETSOURCE, you wouldn't necessarily 
benefit from splitting the source/display resource, but it still 
might be very convenient to do so.

This is why I keep coming back to the desireability of DAV:source. 
It should be fixed, and its support encouraged.  But there also needs 
to be room for people who prefer the simplicity of the single URI, 
who just use DAV for messing with source, and who don't benefit from 
differentiating source/display URIs.

cjh

--