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.

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

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.

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

If I were to spend a programmer month implementing DAV:source, 
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 
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).

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

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

cjh

--

Received on Thursday, 28 February 2002 14:34:45 UTC