Re: Translation in the Tower of Babble

   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