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

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

I disagree. The way it's spec'd is broken. Not the generic concept.

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

The example I gave was not about *forbidding* the modification, it was about
allowing the user agent to *discover* the files on which this
compiled/generated file is based (so it can offer to edit *those* instead).

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

Sure.

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

Yes. So?

For instance, the source property for an executable might contain hrefs to C
sources and a Makefile.

What I'm saying is that the executable and it's output are different
resources (not different representations of the same resource) and thus
should have different URIs.

So, if we would have the URIs

a) <prefix>/sources/hello-world.c
b) <prefix>/sources/Makefile
c) <prefix>/bin/a.out
d) <prefix>/greeting

then c) would have the sources a) and b), while d) has the source c).

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

To take the popular use case (IIS and ASP files): an ASP file generates HTML
output, so the source property of the HTML output resource should/can point
to the ASP resource. Just because Microsoft decided a few years ago that
keeping both the output and the script at the same URI (for Frontpage)
doesn't make this the only possible approach.

Generelly, if a server doesn't know the source (or only some of them), or if
it doesn't want to expose them, that's fine. It's just a pointer for a user
agent where to find the editable source(s).

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

I was saying that we really don't have interoperable implementations, unless
you can properly define what the Translate header means on each single
HTTP/WebDAV method *and* get consensus on that and show that all Microsoft
products are consistent with this.

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

That doesn't mean it's good practice. See [1] (by Tim BL himself).

[1] <http://www.w3.org/Provider/Style/URI.html>

Received on Thursday, 28 February 2002 13:56:12 UTC