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

From: [email-masked]
Date: Tue, 18 Jan 2000 14:05:19 -0500

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.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 20 Jan 2000 16:33:50 -0800

>You are trying to emphasize the definition of a resource as being in

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.

>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
>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.