RE: Translation in the Tower of Babble

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:esedlar@us.oracle.com]
> Sent: Wed, January 05, 2000 1:42 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org; gclemm@atria.com
> 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" <yarong@Exchange.Microsoft.com>
> To: "'Eric Sedlar'" <esedlar@us.oracle.com>
> Cc: <w3c-dist-auth@w3.org>; <gclemm@atria.com>
> 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:esedlar@us.oracle.com]
> > > Sent: Monday, January 03, 2000 4:09 PM
> > > To: Yaron Goland
> > > Cc: w3c-dist-auth@w3.org; 'gclemm@atria.com'
> > > 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
> >
>

Received on Wednesday, 5 January 2000 12:53:56 UTC