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

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.

Received on Tuesday, 18 January 2000 14:06:24 UTC