RE: A case for GETSRC (or other mechanism to that effect)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, February 28, 2002 10:25 AM
> To: Julian Reschke; w3c-dist-auth@w3c.org
> Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
> I think the point is that for every method other than GET, the method
> operates on a particular source object, not a set of them.  dav:source is
> actually trying to track one level beyond that.  Translate: F, or
> GETSRC, is
> just trying to get back the same contents that were PUT to that location.

Actually, with dav:source and multiple URIs PUTting to the non-source result
would result in an error (or at least wouldn't have any effect at all).

> The only time Translate/GETSRC is relevant is for executables (cgi's,
> servlets, etc.) at a particular URL which generate some dynamic content.

I don't agree. DAV:source may be relevant for "compiled" resources as well.
For instance, static HTML might be generated by a one-time compilation
process, but you don't want anybody to *modify* the HTML. Rather, people
would need to be pointed to the modifiable source (for instance, XML and
XSLT input files).

> So, there are really three different sets of content we are looking at:
>
>   1)  the generated output returned by GET
>
>   2)  the executable that generates the content for GET, and which is the
> object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK,
> MOVE, COPY,
> ...)

I don't think I agree. PROPFIND etc. should access the same resource as GET
(if they are applied to the same URI).

>   3)  the multiple source files that were used to generate the executable
>
>
> The GET method returns resource #1, dav:source (if it were actually
> implemented by anyone) would list #3.  Translate: F, or GETSRC, returns
> resource #2, which is the one logically consistent with the other WebDAV
> methods.

Yes, but dav:source can do this for you as well. Why have two different
models if one is enough?

> Actually figuring out #3 is something the equivalent of makefile
> dependency
> tracking, and is not generally available even in a development
> environment,
> which is something that WebDAV is certainly not.

That would only be a problem if WebDAV required that the list of sources is
exhaustive. It doesn't. It's just a hint to a client where to look for files
that actually *affect* the resource when edited.

> Real-world experience has shown that:
>
> * nobody actually tracks multiple source files for an executable
> * people sometimes want to actually get the executable contents
>
> Nobody has actually come up with a real-world use-case for dav:source, but
> whether or not dav:source is deprecated or not, it's actually
> identifying a
> different set of content than Translate: F / GETSRC.

I disagree. Could you please explain why the model used in DAV:source can't
be applied to this use case?

> And, once you realize that you need Translate: F or GETSRC, you might as
> well use Translate: F, as you will have no problem getting interoperable
> implementations, and it is functionally equivalent to GETSRC.

Using the same URI for "the" source (assuming there is only one) and the
output means that you can't point people explicitly to one of them. As user
agents generally aren't aware of the Translate header (or GETSRC), they
would fetch the output resource, so basically you have a source resource
which you can't refer to.

Actually, having a one-to-one mapping of executables to their output (for
instance foo.asp) is a very bad practice. Everytime you change your
underlying implementation, URIs will change. However, cool URIs don't
change.

Julian

Received on Thursday, 28 February 2002 06:00:00 UTC