- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Thu, 20 Jan 2000 16:33:50 -0800
- To: ccjason@us.ibm.com
- cc: w3c-dist-auth@w3.org
>You are trying to emphasize the definition of a resource as being in >the eyes of the author. Yes, and not just trying -- that is the definition of a resource. The definition derives from the central requirement of the Web: independent authoring of interconnected hypertext across multiple trust domains. Forcing the interface definitions to match the interface requirements makes some things *seem* vague, but that is only because the interface being manipulated is only an interface and not an implementation. >And that you want the server somehow be able to know and track the author's >concept of "the resource"... and distinguish it from the current >implementation of the resource. That's not quite what I meant. What I was saying is that IF the spec is going to make a distinction between bindings and resources, THEN the protocol must provide a mechanism for the author to communicate that distinction to the server. IF, instead, the interface simply assumes that all bindings are separate resources (as does RFC 2616), then there is no need for that communication mechanism. Don't get me wrong: there are some advantages to having a protocol mechanism for identifying true aliases of a resource outside of DAV (e.g., elimination of replicas in caches), but in the past those advantages haven't been worth the effort. > And because bindings remove the tight one-to-one association >of the conceptual resource from its implementation, you feel the advent of >bindings is a good place to have the server start maintaining that >separation and support both concepts fully. No, that's where lossage occurs in this discussion. A resource is not the storage object. A resource is not the mechanism that the server uses to handle the storage object. A resource is a conceptual mapping -- the server receives the identifier (which identifies the mapping) and applies it to its current mapping implementation (usually a combination of collection-specific deep tree traversal and/or hash tables) to find the currently responsible handler implementation and the handler implementation then selects the appropriate action+response based on the request content. None of this implementation is part of the Web interface. For example, consider what happens when a site grows in user base and decides to replace its old IIS server with a brand spanking new Apache server running on a Sun ULTRA. The disks are replaced. The operating system is replaced. The HTTP server is replaced. Perhaps even the method of generating responses for all of the content is replaced. What doesn't change is the Web interface: if designed correctly, the namespace on the new server can mirror that of the old, meaning that from the client's perspective, which only knows about resources and not about how they are implemented, nothing has changed aside from the improved robustness of the site. (;-) So, while it is okay for the bindings spec to say that bindings are somehow different from resources, it is absolutely critical that it not equate resources to some part of the server implementation. Call those other things handlers if you like, but understand the difference when interpreting what the existing HTTP requirements mean, because those HTTP requirements are on resources and resource identifiers, not on handlers. ....Roy -- Meet me at ApacheCon 2000 <http://www.apachecon.com/>, March 8-10.
Received on Thursday, 20 January 2000 19:34:02 UTC