- From: <ccjason@us.ibm.com>
- Date: Tue, 18 Jan 2000 14:05:19 -0500
- To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
- cc: w3c-dist-auth@w3.org
I agreed or didn't understand various parts of your note until I got to the following. I think it explains what you're trying to get at when you speak of the server knowing if something is the same resource or not. >> 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. >> You are trying to emphasize the definition of a resource as being in the eyes of the author. 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. 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. It sounds like you'd like to be able to insert another level of indirection in our model. A "a-resource" is the author's conceptual resource. A "s-resource" is a server's concept of a resource and represents an implementation. URI: leadprogrammer.html john.html fred.html ---------------- aresource: lead_programmer_personal_page aresource: john aresource: fred ----------------- sresource: John.html sresource: John.pl sresource: Fred.html ------------------- states of sresources: John.html.001 John.html.002 John.pl.001 Fred.html.001 The "binding" from URI to aresource is pretty static. The URI basically should continue to point to the same concept until the end of time.... ideally. OTOH over time the author might change the implementation to use a different sresource for a given conceptual resource. And over time the implementation of the sresource might evolve as it is debugged. So what we've done in WebDAV is compressed the URI and conceptual resource layers together since ideally they should remain as a one:one mapping for eternity. That means if we have a situation like... leadprog.html john.html fred.html | | | lead_prog john fred \ / | \ / | John.html Fred.html In webdav we'd create a situation like the following. leadprog.html john.html fred.html \ / | \ / | John.html Fred.html >> And you are thinking of the resource as an implementation of the resource rather than the resource. >> Actually I was thinking both. I was emphasizing the server's concept as something that the author could still leverage to maintain his concept. I didn't feel it was important for the server to maintain the author's concept of a resource, but I felt that if the author wanted the server to, it could. That's what I meant when I spoke about a proxy object. What I was saying about a proxy object is that the author could actually create a server resource to represent his concept of a resource and distinguish it from its implementation. That object would not implement anything. It's only job would be to redirect to the server object that currently implements the authors concept. The server could manage both the conceptual resource and the implementation resource as WebDAV resources. The fly in the ointment is that ideally we'd like the proxy object to have a ***strong*** link/binding (whatever you want to call it) to its implemenation object. The only type of strong links that we provide right now are bindings. And they are only kept by collections. So this proxy object would basically need to be a collection. Presumably that collection would only be allowed one child and it would always internally redirect to it. Of course it can't always redirect ALL requests. Presumably there are operations that we might want to do on the proxy itself. (Maybe there aren't.) Anyway, the basic ground work is there to do this if the author wants to. It isn't explicitly supported in the protocol though. It could be at a later date though. As I said, the ground work is there. BTW... you mentioned that BIND acts on the wrong object. I think most of us recognize this, but I just wanted to remind you to get back to us with your commments and insight on that. Jason.
Received on Tuesday, 18 January 2000 14:06:24 UTC