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 03:22:20 UTC