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

From: [email-masked]
Date: Mon, 17 Jan 2000 20:29:17 -0500

Roy, thanks for what you said in the first part of this note.

  And whatever you think while reading this, keep in mind that the resource
  is not the storage thingy on the back-end -- it is the concept being
  referenced by the originator of the URI.

Agreed.

  I don't understand how
  the server is supposed to know what the resource is when the user is
  allowed to create new bindings willy-nilly.  Therefore, either the
  server needs to be told what the resource is when the bindings are
  created (which doesn't seem likely, since most of the users wouldn't
  understand the difference) or the definition of DELETE should be changed
  to reflect the easier-to-grasp notion of removing the binding.

Are those the only choices?...

Can't we leave the definition of resource suitably vague as we and
our predecessors have?  If we do I suspect servers will drive a
WebDAV compliant definition that content authors on their site will
use.  Not the opposite.

  Almost all servers will support the model of
flat/dead file or repository object that basically is just an echo of
a PUT/GET.provide their own underlying meaning of resource.    A server
might also offer support for more intelligent objects like servlets or
perl scripts and also treat those as resources.  The author's job is
to encapsulate his concept of a resource within the one of the server's
concepts of a resource which is probably a file or some sort of
repostiory object.

As I just said, most of the time, the server will drive a WebDAV compliant
concept of a resource that that the content authors will use.
One likely  exceptions is the concept of a resource essentially being
at the URI.  This model doesn't need server support and may not leverage
the server model or even necessarily the WebDAV model of resource.  An
example is,
"page_of_the_day.html".  Certainly the author could use a proxy
resource that essentially gets it's contents from other resources depending
on today's date, but it's more likely that the author will just choose to
rebind that URI each day.  Sure, the casual referencer's
concept of the resource will not be the same as the server's, but the right
thing happens.  Does it matter that the author chose to have one foot in
each model?

Jason.

PS. I hate HTML mail too.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 17 Jan 2000 20:26:12 -0800

>Are those the only choices?...

All that I can think of at the moment.  Another way to put it is:
if the server is not informed of the difference between a new binding to
an existing resource and a new binding representing a new resource that
happens to currently point to an existing resource, then the server must
treat all bindings as unique resources.  The alternative---that all
bindings to the same resource represent a single resource---is known
to be false.  If the server is treating all bindings as unique resources,
then DELETE on a binding is equivalent to DELETE on a resource.

Since we have a good grasp of what it means to DELETE a binding, and
we can assume that the server can be configured to act appropriately
when the last accessible binding is deleted from a resource, I think it
is reasonable to alter the definition of DELETE so that it follows the
spirit of what is defined in RFC 2616 rather than the exact terminology.

Well, either that or simply declare that every binding is a separate
resource, even when it isn't.

Or, declare a new method called UNBIND that removes bindings but not
resources.  I guess then the WG would have to figure out what should
happen when the client attempts to UNBIND the last binding attached to
a resource, and likewise BIND would have to indicate whether the new
binding should be considered a new resource or an alias of an existing
resource.  I pretty much assumed that the WG had already discussed this
option and moved on.

>WebDAV compliant definition that content authors on their site will

Hmmm, my experience is that most implementers will randomly stagger
towards the first implementation that appears to work for their limited
test set, and then refuse to fix it out of fear of breaking backwards
compatibility.  Only those who understand the overall architecture are
likely to get it right the first time.

>concepts of a resource which is probably a file or some sort of

Actually, no.  If we treat the web as if it were a distributed filesystem,
it will eventually lose those qualities that make it better than a
distributed filesystem.  The most important goal of WebDAV is to enable
manipulation of resources without assuming anything about how the
resource is implemented; it is okay to learn how it is implemented
during the process of interaction, but only to the extent that the
server reveals that information to the client.  So we build up this
interface model where the client makes operations on the generic interface
and then the server translates those operations into the mechanism
applicable for that resource.

Namespace operations are a little unnatural in that, even though the
request-URI consists of the target name, the actual mechanism targeted
by the request is the collection resource that governs that namespace.
Hence, MOVE changes the collection, not the resource.

[Gack! I just noticed that the request target of a BIND request is,
well, wrong in the spec. More on this later.]

>thing happens.  Does it matter that the author chose to have one foot in

I don't follow that -- I only see one model there, even if the
"page_of_the_day.html" is a physical file on the server.  How it is
implemented doesn't make any difference to the interface presented
to the client except during the authoring operations.

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.

....Roy