RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests]

I agree with 1a (leave things alone), but then I again suggest that we add
507 to the list of possible response coded so a server can respond with
"Partial Results Sent"  This way a server can stop a request if necessary.

Kevin


-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan
Sent: Friday, July 07, 2000 12: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 Saturday, 8 July 2000 12:40:53 UTC