Re: [dav-dev] Depth Infinity Requests]

The proposal to allow a depth value other than 0,1,infinity
has been motivated by some very clear and common use cases
(i.e. either deliberately or mistakenly invoking PROPFIND on
the root of a very large resource tree).

Arguments of the form "it would be simpler to only allow 0,1,infinity"
do nothing to address the use case that is of concern.

One of the postings used the fact that a "find" request does not have
a depth argument to support the position that a PROPFIND request
should not need one either.  I believe this argument does not hold
for a variety of reasons, such as the fact that "find" is almost
always used with a predicate (commonly "name"), and that the OS
commonly provides job control and a data pipe mechanism to control
the behavior of find, neither of which are available with a
PROPFIND request.

Cheers,
Geoff


-----Original Message-----
From: Babich, Alan [mailto:ABabich@filenet.com]
Sent: Friday, July 07, 2000 3:36 PM
To: 'Jim Davis'; WebDAV WG
Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests]


I wasn't trying to promote the UNIX find command as an
example of good design. I was only trying to make a point 
about the KISS principle. In fact, "find" does not have the
simplest design for the normal case.

The only way I ever use the UNIX find command is:

    find <directory> -name <file name specification> -print

This just displays the full path name of the file(s) I'm 
looking for. I completely ignore all the other powerful 
functionality. So, from the point of view of the way I use it, 
it is very simple. It would be even simpler if I didn't have 
to figure out that I had to add "-name" and "-print" to get 
what I want. The designers and implementors wasted (as far 
as my case is concerned) all their valuable time and effort 
implementing features that I don't use, and made it more 
complicated for me to figure out (as a side effect of the 
additional features). I assume that somebody out there thinks 
that some of the other features are critical, so that
the effort and increased complexity isn't entirely in vain.

My point is that my experience with this particular command 
supports the approach of "cut features until you are about 
to cut too far, then let customers tell you what features to 
add on subsequent releases". That approach tends to maximize
the simplicity of the normal case and ease of implementation,
and things tend to get added in priority order.

So, I'm in favor of (a) in your e-mail below -- no change.

Alan Babich

-----Original Message-----
From: Jim Davis [mailto:jrd3@alum.mit.edu]
Sent: Thursday, July 06, 2000 11:22 PM
To: WebDAV WG
Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests]


At 08:21 PM 7/6/00 -0700, Babich, Alan wrote:

>... the increased 
>complexity might not be worth the decreased simplicity. I like
>the KISS principle. The UNIX find command doesn't have a way
>to specify a limit on the depth. 

Poor example, in support of a good argument.  The find command has dozens
of options, including general boolean combinations of predicates.  If Unix
find is your idea of something simple, I would hate to see something you
thought complex.

That said, it seems to me there are now three related proposals on the
floor.  They are
 1. change the values accepted in the depth header
 2. change the responses the server may return
 3. provide means for client to abort a request that is taking too long.

Of these, there are four alternatives for proposal 1:

a) depth may be only 0 or 1, or infinity (what we have now)

b) depth may be only 0 or 1

c) depth may be an integer, but not infinity.

d) depth may be an integer, or infinity

Proposal 2 is to add a response code the server may use to reject a
request, either because the specified depth is too great, or because the
results would be larger than the server is willing to return.  This
proposal only makes sense if for proposal 1 one prefers a, c, or d.

Proposal 3 is to add a mechanism where the client can abort a request that
has taken too long.

[I believe, but am not sure, that a client can simply close the connection]

Proposal 1 is the linch-pin.

the arguments for alternative a are that it's just what we have now.

the arguments f(I have seen) for b are
 * it is even simpler than what we have now

 * if one rejects it,  then if any client that can tolerate a refusal
(proposal 2) would have to be able to operate in depth-one mode anyway.  if
one takes the trouble to code the client to be able to work with
single-depth requests anyway, why would one even bother using the depths
greater than one?  it's just more code to write.

 * given pipelining, there would be little performance penalty.

Received on Friday, 7 July 2000 16:30:34 UTC