Re: WebDAV Bindings - Issue Yaron.Insulting2616, definition of resource

>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