Subject: RE: Translation in the Tower of Babble

From: Yaron Goland <[email-masked]>
Date: Wed, 5 Jan 2000 09:53:01 -0800

A'int that the truth.

Although I'm now in negotiations for a new position at MS that would allow
me to return my attentions to WebDAV. So Geoff, don't get too comfy. =)

			Yaron

> -----Original Message-----
> From: Eric Sedlar [mailto:[email-masked]]
> Sent: Wed, January 05, 2000 1:42 AM
> To: Yaron Goland
> Cc: [email-masked]; [email-masked]
> Subject: Re: Translation in the Tower of Babble
> 
> 
> Well the bottom line is whether or not Geoff is interested in 
> using such a
> model ;-)
> 
> --Eric
> 
> ----- Original Message -----
> From: "Yaron Goland" <[email-masked]>
> To: "'Eric Sedlar'" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, January 03, 2000 6:00 PM
> Subject: RE: Translation in the Tower of Babble
> 
> 
> > Actually I started down the path of trying to write a 
> general model for
> > WebDAV in
> > 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0
> 020.html but
> > no one seemed really enthusiastic about the project.
> >
> > > -----Original Message-----
> > > From: Eric Sedlar [mailto:[email-masked]]
> > > Sent: Monday, January 03, 2000 4:09 PM
> > > To: Yaron Goland
> > > Cc: [email-masked]; [email-masked]'
> > > Subject: Re: Translation in the Tower of Babble
> > >
> > >
> > > Yaron,
> > >
> > > The problem with discussing abstractions like this without
> > > concrete examples is
> > > like trying to write legislation without loopholes--you don't
> > > really know if
> > > it's well written until you see its effects.
> > >
> > > My guess is that the direction you are heading in is defining
> > > a resource as the
> > > base class of all WebDAV objects capable of responding to an
> > > HTTP request.
> > > This is a good abstraction.  It follows from this that an
> > > HTTP method like LOCK
> > > should not apply to a URL that does not identify a resource,
> > > since there is no
> > > resource to respond to the request, which would outlaw the
> > > lock-null approach.
> > >
> > > It might be useful to give more of an "agenda" for where this
> > > thread is going
> > > (even without filling in the details), so people can 
> better place your
> > > discussion in context of the world of WebDAV problems.
> > >
> > > In general, however, I think that any solution to the 
> locking problems
> > > discussed recently has to fit in some general model like the
> > > one I anticipate
> > > that Yaron will propose.  However, I prefer a complete model
> > > to be laid out
> > > before me before I comment on particular precepts of the model.
> > >
> > > For example, following this level of abstraction, we should
> > > define a resource
> > > better.  I would say that a resource has a set of properties,
> > > which can be
> > > represented via an XML document.  Some of these properties are
> > > "live" properties, which are read-only and are set as a side
> > > effect of other
> > > methods ( for example a modification date).  Attempts to set
> > > the value of a
> > > live property directly via generic property mutator method(s)
> > > (e.g. PROPPATCH,
> > > PUT, etc.) should always be ignored.  A collection is a
> > > subclass of resource
> > > that has a live property containing a list of tuples
> > > including at least a name
> > > (and possibly with other values such as a resource ID
> > > associated with that
> > > name).  A BIND request is treated as a method that modifies
> > > the values of the
> > > collection's name tuple list.
> > >
> > > This should all be worked into the versioning model document
> > > (http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209
> > /), which while
> > defining some of the functional methods available on a 
> resource, doesn't
> > define
> > the properties on a resource as well as a number of the 
> other assumptions
> > along
> > the lines Yaron proposes.
> >
> > --Eric
> >
> >
> >
> > Yaron Goland wrote:
> >
> > > I believe that there are too many different unstated 
> assumptions held by
> > > members of this group for this group to be ready to deal 
> with specific
> > > locking proposals. The fact that Geoff, Eric and RFC 2518 
> can come out
> > with
> > > such different proposals helps to illustrate the issue. 
> Rather than
> > > attempting to achieve consensus in one fell swoop by 
> having everyone
> read
> > > and critique full proposals I would suggest that we start 
> from a simpler
> > > basis. Let us first see if we can establish agreement on 
> some very basic
> > > precepts. I will start with just one precept and see if we can get
> > agreement
> > > on just that.
> > >
> > > Precept #1 - HTTP clients send HTTP request messages to 
> resources that
> > > respond with HTTP response messages.
> > >
> > > Corollary #1.1 - All HTTP proposals can only be written 
> in terms of how
> a
> > > resource processes a HTTP request from a HTTP client and 
> generates a
> HTTP
> > > response as a result.
> > >
> > > Corollary #1.2 - HTTP requests do not necessarily have to 
> be handled by
> > HTTP
> > > resources. For example, it is possible to send a HTTP 
> request with a FTP
> > > request-URI. Some HTTP proxies are set up to act as 
> gateways that can
> > handle
> > > translating the HTTP request into a FTP request and then 
> translate the
> FTP
> > > response into a HTTP response. That is why precept #1 
> states "...to
> > > resources..." rather than specifying a HTTP resource.
> > >
> > > Corollary #1.3 - Since HTTP request messages can only be 
> handled by
> > > resources which respond with HTTP response messages then 
> even error
> > messages
> > > such as "Not Found" must have been generated by a resource.
> > >
> > > Let's see if we can just get agreement on this single 
> precept and its
> > > corollaries.
> > >
> > >         Merci,
> > >
> > >                         Yaron
> >
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 5 Jan 2000 23:25:29 -0500

using such a model ;-)

   From: Yaron Goland <[email-masked]>
   A'int that the truth.
   Although I'm now in negotiations for a new position at MS that would allow
   me to return my attentions to WebDAV. So Geoff, don't get too comfy. =)

Well, I'm far more interested in getting it right than being
comfortable (:-), so I'm all for any change that increases Yaron's
participation.

Now, as for the object model.  I am an enthusiastic supporter of
the creation of an object model, and support most of Yaron's first
pass at such a beast (except for the semantics of DELETE).

In fact, his model clearly illustrates (to me, anyway :-) the
problems associated with trying to postulate a "null resource"
that handles methods applied to URL's that are not bound to a
"real" resource.

For example, consider the PUT method.  Yaron models this as:
   PUT(N,G):
   R = NR(N);
   If (R != NULL) {
      R.GET = G; // Future responses to GET will be G
      return;  }
   R' = R.CreateNewResource();
   NR(N) = R';
   R'.GET = G;
   return;

Note that this is not modeled as functions on resources,
but rather as a computation being performed by some other
entity (I'll call it a "server") that has the key piece of
data, "NR", which defines the current name-to-resource mapping
defined by that server.  But to be fair, we should examine
whether this function could be recast as a function on the
current resource identified by that URL.

I'm willing to let the "R = NR(N)" slide, and agree that could
be modeled as the implicit dereferencing of a name that is
automagically performed before any request is "handled".

The "If" statement could be just a placeholder for a type dispatch,
and then the R.GET=G is clearly a method on the resource, so we're
fine until then.

But then we get to the case where the method is being handled by
the "null resource" (R == NULL).  Having "CreateNewResource" as
a method on R is somewhat suspect, but I probably could live with that.
It's the next line, "NR(N) = R", that illustrates the problem.
Where did NR come from?  My answer would just be that the PUT method
is really being handled by the *server* (which has an "NR" feature),
and is only dispatched to a resource when there already is a resource
bound to the specified name.

The DELETE method is also clearly handled by the object that owns the
NR map (i.e. what I'm calling the server).  Here, I'll use my
definition of DELETE (but the same argument applies to Yaron's
definition):

   DELETE(N):
   If (NR(N) == NULL) {
      error("no resource at specified URL");
      return;
   }
   NR(N) = NULL;
   return;

Again, DELETE is a method that is handled by the server (i.e. the
object that owns the NR attribute), not by the resource currently
bound to the specified URL.

As Jason points out though, Yaron's initial model (which I think
is a good model for HTTP, and so I'll call it "the HTTP model")
does not adequately model the collection semantics of WebDAV.
To do so, we have to supplement the "NR" feature of a server with
the "bindings" feature of a collection.  Since this is probably
a separate thread, I'll address this in a subsequent message.

Cheers,
Geoff