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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Thursday, February 28, 2002 2:59 AM
> To: w3c-dist-auth@w3c.org
> Subject: 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).
>

My point is not that dav:source is relevant (it is clearly useful to look at
the source files as in your example), but whether or not it is useful (three
years of industry experience say clearly it is not) is irrelevant to whether
or not Translate/GETSRC is useful.  You have pointed out a case (like
regular files) where GET and GETSRC would return the same result.  Whether
or not you want to allow people to directly write to compiled output (or an
executable) is a separate issue (which could be handled via an ACL, or the
server could generate an error).

> > 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?
>

dav:source deals with a completely separate use case.  I clearly need to
separate out the executable at the current URL from the files that generate
it.  In the case of a compiled executable, would you recommend putting both
the executable URL and the .o's & .c's that generate it in the same
undifferentiated dav:source bucket?  It's clearly necessary to separate the
two sets of things, for the case when you can directly PUT to the executable
resource.

> > 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?
>

You disagree?  Can you point to any implementations that actually keep track
of the source files?  I'm not saying you can't make up an example, just that
in practice, servers don't keep track of the references to the source.

> > 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.
>

So you are using the existing practice argument?  Existing user agents
aren't aware of dav:source either, so in any case we are talking about new
functionality.

> 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.
>

What URIs are you talking about?  Can you give an example of this?  Clearly
there is widespread industry support for the one-to-one mapping you describe
(cgi, .asp).

--Eric

Received on Thursday, 28 February 2002 12:44:39 UTC