- From: Adam Freeman <afreeman@lightsurf.com>
- Date: Mon, 29 Oct 2001 16:51:01 -0800
- To: "Roy T. Fielding" <fielding@ebuilt.com>, "Jim Whitehead" <ejw@cse.ucsc.edu>
- Cc: "WebDAV" <w3c-dist-auth@w3.org>
Hello, While the link property is a little funky, it addresses a common problem: having two (OR MORE) different sets of properties for the same resource. Having a GETSRC and a GET for the same resource limits you to having two representations of the resource, the original and the modified (or authored or whatever you want to call it). What if you want a third representation of that resource? With the link property, you can accomplish that (I think). GETSRC should return the same thing that a GET without any properties should return. It seems redundant. Why not just have more than one set of properties. GET with blank properties is the same as GETSRC. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding Sent: Monday, October 29, 2001 4:22 PM To: Jim Whitehead Cc: WebDAV Subject: Re: Ideas: GETSRC & MULTIPUT > The source link didn't work. Telling people to use the source link is not, > IMO, productive. Under what conditions did it not work? Do you mean just never implemented? > GETSRC could be defined as something like, "returns to the client a > representation of the resource suitable for editing in an authoring client", > so we avoid issues of getting at the "true" state of the resource. GETSRC > wouldn't have the same caching properties as GET; I don't see that as being > a big problem for authoring. > > So, which specific HTTP design principle(s) does this proposal violate? The one that calls for different resources to be accessed using different URI. The set of source URI for some other URI are different resources. Since there can be many more than one source per representation, the notion of creating a new method to avoid one indirection is just wrong. ....Roy
Received on Monday, 29 October 2001 19:51:31 UTC