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

I agree with Julian's question, i.e. why don't you just use
some natural URL to expose your editable source.  In general, the
file extension of the actual file containing your editable source
will not be ".html".  It will be .asp, .jsp, or whatever.  So the
natural URL for the jsp source for /x/y/foo.html is /x/y/foo.jsp.
Why not just use that URI to identify your source resource?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, February 28, 2002 3:38 PM
To: CJ Holmes; w3c-dist-auth@w3.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 CJ Holmes
> Sent: Thursday, February 28, 2002 8:33 PM
> To: w3c-dist-auth@w3.org
> Subject: 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).
>
>
> Agreed.  I am not arguing against DAV:source at all.  I think it is a
> good idea, and I recognize its architectural superiority.
>
> What I object to is that the current model makes simple things very
> hard to implement and a hassle to manage for no real gain to most
> people.

I think you need to prove that if you want to introduce a second model for
something that could be solved using DAV:source.

> >  > 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,
> >  > ...)
> >  >   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?
>
> Nobody is suggesting two models.  I'm suggesting a change in the
> current model.  Instead of GETSRC, let's call it DAVGET just to
> relieve us of some preconceptions.
>
> 	GET is undefined by DAV
> 	PUT and DAVGET are symmetric
> 	Properties belong the result of DAVGET
> 	If URI "x" is compiled from sources at other URIs, then:
> 		DAVGET "x" will retrieve the resource
> 		PROPFIND "x" will retrieve the properties of DAVGET "x"
> 		GET "x" would probably return the same resource as
> DAVGET "x" (impl dependent)
> 		PUT "x" will result in an error (impl. dependent),
> since the sources lie elsewhere.
> 		PUT to the source URI(s) of "x" will affect the
> properties and value of DAVGET "x"

Having a new GET method that returns completely different resources than
GET, and defining that PROPFIND operates on DAVGET rather than GET is not
only a new model, it would change WebDAV at it's core. Why do this if this
isn't needed????

> You can still have DAV:source and it will be just as useful as it is
> now.  But the common problem of how people use DAV to edit their
> source files is resolved.

It can *easily* be solved using DAV:source.

> >  > 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?
>
> It can, but it just isn't worth the trouble.  It is a LOT of extra
> work for absolutely no gain.  You gain nothing from DAV:source that
> you don't get for 1/20th the work from Translate.

That's a broad claim. Can you prove it?

> If I were to spend a programmer month implementing DAV:source,

Why would that take so long?

> administrators would still have to set aside special URL spaces and
> turn off all plug-ins for that space and add a lot of new security

No, they don't.

Nobody says that they *have* to set aside a special URL space.

For instance, for any "output" resource "x", you could have a source
resource "x" + ".~~~~~source~~~~~" which represents the editable source code
of this resource. No separate URL space.

> realms, just like they do now.  We could implement it, but in terms
> of managing the server we're left with the same mess that already
> afflicts our users.  There's just no point in implementing DAV:source
> unless you have some kind of tightly-integrated document
> management/compilation system that tracks multiple sources for the
> GET results of dynamic URI(s).

The only difference is that you might have more than one source. It escapes
me why the special case of having just one source justifies breaking basic
Web axioms by having different resources with the same URI.

> And so we're left in a situations where the simplest task is
> quite difficult.

No, it's not.

Maybe you could step back and describe why you think it's so much more work
generating a second URI for the editable source resource.

> >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.
>
> Nobody is trying to tie down executables to output on a one-to-one
> basis.  Nobody is trying to get rid of DAV:source.  We're just trying
> to adjust the current model to make the simple things easy, while
> maintaining support for the the difficult (and architecturally more
> interesting) things.

Received on Thursday, 28 February 2002 17:10:44 UTC