RE: Issue: ALLPROP_AND_COMPUTED

There is still a problem to solve, and it's not directly the expensive
computations, though it is a result of that.  Now that specs which extend
RFC 2518 explicitly state that their properties should not be returned in an
'allprop', it no longer has the meaning it used to and clients need to be
made aware of that.  "Cat out of bag".

From the client point of view, 'allprop' could be deprecated, repurposed, or
renamed.
 - Deprecated would amount to "don't use allprop".
 - Repurposed would be "use it, but it doesn't mean what you think it means
(it doesn't return all properties)".
 - Renamed it would presumably be 'coreprop' and return the properties
defined in RFC2518 (except perhaps for lockdiscovery).

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Tuesday, May 01, 2001 9:45 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Issue: ALLPROP_AND_COMPUTED
>
>
>
>
> Hey everyone.  I didn't mean to silence everyone with my note below.   I
> think Jim still needs opinions to figure out the disposition of
> this issue.
> Do we have any more comments?
>
> I'll propose that we put this off until we know if there is an actual
> problem.  Perhaps someone who felt there was a problem could speak up and
> add an opinion.  Do you still think there is a problem that we need to
> solve?
>
> J.
>
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
>
>
> Jason Crawford/Watson/IBM@IBMUS@w3.org on 04/28/2001 02:03:04 PM
>
> Sent by:  w3c-dist-auth-request@w3.org
>
>
> To:   Greg Stein <gstein@lyra.org>
> cc:   WebDAV WG <w3c-dist-auth@w3.org>
> Subject:  Re: Issue: ALLPROP_AND_COMPUTED
>
>
>
>
>
> <<
> The issue isn't tossing allprop, but providing a warning to clients about
> dealing with expensive computed properties.
>
> Removing allprop does not solve the computed problem. Since allprop *is*
> useful, then there is no reason to remove it.
> >>
> I agree with Greg.  We can still have this size problem with depth one and
> depth zero.  And FTP's MGET can have a similar problem and we don't hear
> people complaining about that.  Are we being overly concerned?  We as
> authors of the spec can't know if this is a problem in advance either.
> Sometimes it will be and other times it won't be.  Let's just deal with
> what a client or server can do in situations where they feel it's a
> problem.
>
> So...
>
> Is it sufficient for a client to simply disconnect/timeout?
> Should we have
> an error code that the server can use if it deems a request too expensive?
> Or is there some other simple approach?  Or should we defer the
> issue until
> version 2.0 if it then looks like this truly is a problem?
>
> J.
>
>
>
>
>

Received on Wednesday, 2 May 2001 10:52:43 UTC