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/0020.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 Tuesday, 4 January 2000 11:30:25 UTC