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

My vote is for 1 d) and 2 but not for anything special for 3 - closing the
connection should actually abort the operation if the server is implemented
correctly.

The reason I believe that we should implement 1 d is that our experience has
shown that the performance gains can be significant when multiple results
are returned from a single request as opposed to performing multiple
requests.

Forcing every client to implement pipelining to attempt to achieve similar
performance is unacceptable.

I further propose that language be added to the spec for proposal 2 stating
that a server make every reasonable attempt to honour the client's request
and possibly even limit the acceptable reasons for not doing so (with
corresponding error response codes).

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Davis
> Sent: Friday, July 07, 2000 2:22 AM
> 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 09:35:02 UTC