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

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

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.

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

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.

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

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

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

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

Received on Monday, 17 January 2000 23:26:17 UTC