- From: <ccjason@us.ibm.com>
- Date: Thu, 6 Jan 2000 12:44:09 -0500
- To: w3c-dist-auth@w3.org
For me, saying that "every resource must be an HTTP resource so that it at least can say that it doesn't understand HTTP requests" is another result of trying to eliminate the concept of a "server" (what Yves calls a "daemon") from the model. I believe a simpler (and more intuitive) model is to just say that there is a server, and if the server sees that a resource at a URL is not an HTTP resource, it returns an "HTTP not supported" response. This is the same server object that owns the NR (name-to-resource) mapping data. Based on what I've seen so far, I tend to agree. I can understand NR() returning NULL (not that I think that NR() should be the basis of the model), but I don't feel that we can say that it's a "NULL resource". I think we should also determine if we should be formally declare that a collection is fundamentally different than a non-collection... or just a matter of having or not having children. I'd also like to say, that in some ways I like EricS's "model". There are a bunch of things that I don't like or feel need to be cleaned up (if possible), but he has presented a way to achieve the LNR functionality without actually having null resources. His model also achieves URI protection without talking about the namespace. I've sent Eric a note with my reservations. Hopefully he'll be presenting an improved version of his model here. Finally, it was LOCKING that kicked off this renewed discussion of our model. It's not clear to me if the model should drive the locking proposal... or if the locking proposal should drive it. Or if they really need to affect each other at all at this point. I certainly wouldn't want to delay progress on locking if we don't need to. Jason.
Received on Thursday, 6 January 2000 12:44:40 UTC