- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Mon, 17 Jan 2000 20:26:12 -0800
- To: ccjason@us.ibm.com
- cc: w3c-dist-auth@w3.org
>> I don't understand how >> the server is supposed to know what the resource is when the user is >> allowed to create new bindings willy-nilly. Therefore, either the >> server needs to be told what the resource is when the bindings are >> created (which doesn't seem likely, since most of the users wouldn't >> understand the difference) or the definition of DELETE should be changed >> to reflect the easier-to-grasp notion of removing the binding. > >Are those the only choices?... All that I can think of at the moment. Another way to put it is: if the server is not informed of the difference between a new binding to an existing resource and a new binding representing a new resource that happens to currently point to an existing resource, then the server must treat all bindings as unique resources. The alternative---that all bindings to the same resource represent a single resource---is known to be false. If the server is treating all bindings as unique resources, then DELETE on a binding is equivalent to DELETE on a resource. Since we have a good grasp of what it means to DELETE a binding, and we can assume that the server can be configured to act appropriately when the last accessible binding is deleted from a resource, I think it is reasonable to alter the definition of DELETE so that it follows the spirit of what is defined in RFC 2616 rather than the exact terminology. Well, either that or simply declare that every binding is a separate resource, even when it isn't. Or, declare a new method called UNBIND that removes bindings but not resources. I guess then the WG would have to figure out what should happen when the client attempts to UNBIND the last binding attached to a resource, and likewise BIND would have to indicate whether the new binding should be considered a new resource or an alias of an existing resource. I pretty much assumed that the WG had already discussed this option and moved on. >Can't we leave the definition of resource suitably vague as we and >our predecessors have? If we do I suspect servers will drive a >WebDAV compliant definition that content authors on their site will >use. Not the opposite. Hmmm, my experience is that most implementers will randomly stagger towards the first implementation that appears to work for their limited test set, and then refuse to fix it out of fear of breaking backwards compatibility. Only those who understand the overall architecture are likely to get it right the first time. > Almost all servers will support the model of >flat/dead file or repository object that basically is just an echo of >a PUT/GET.provide their own underlying meaning of resource. A server >might also offer support for more intelligent objects like servlets or >perl scripts and also treat those as resources. The author's job is >to encapsulate his concept of a resource within the one of the server's >concepts of a resource which is probably a file or some sort of >repostiory object. Actually, no. If we treat the web as if it were a distributed filesystem, it will eventually lose those qualities that make it better than a distributed filesystem. The most important goal of WebDAV is to enable manipulation of resources without assuming anything about how the resource is implemented; it is okay to learn how it is implemented during the process of interaction, but only to the extent that the server reveals that information to the client. So we build up this interface model where the client makes operations on the generic interface and then the server translates those operations into the mechanism applicable for that resource. Namespace operations are a little unnatural in that, even though the request-URI consists of the target name, the actual mechanism targeted by the request is the collection resource that governs that namespace. Hence, MOVE changes the collection, not the resource. [Gack! I just noticed that the request target of a BIND request is, well, wrong in the spec. More on this later.] >As I just said, most of the time, the server will drive a WebDAV compliant >concept of a resource that that the content authors will use. >One likely exceptions is the concept of a resource essentially being >at the URI. This model doesn't need server support and may not leverage >the server model or even necessarily the WebDAV model of resource. An >example is, >"page_of_the_day.html". Certainly the author could use a proxy >resource that essentially gets it's contents from other resources depending >on today's date, but it's more likely that the author will just choose to >rebind that URI each day. Sure, the casual referencer's >concept of the resource will not be the same as the server's, but the right >thing happens. Does it matter that the author chose to have one foot in >each model? I don't follow that -- I only see one model there, even if the "page_of_the_day.html" is a physical file on the server. How it is implemented doesn't make any difference to the interface presented to the client except during the authoring operations. A better example is a collection consisting of "Fred", "Frederick", and "Douglass". Those could be three different resources (for example, individuals within a team of coders) or three different aliases for the same resource. The only person who really knows the answer is the person defining the namespace -- it just isn't something that a server can figure out by analyzing the implementation, because what differentiates one resource from another is the semantics given to them when each URI is used within some external reference. The server can't even rely on the implementation giving some indication of the difference, since the implementation is allowed to change over time, whereas the semantics of a resource does not (legitimately) change over time. ....Roy
Received on Monday, 17 January 2000 23:26:17 UTC