Subject: RE: Issue: ALLPROP_AND_COMPUTED

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 2 May 2001 23:53:27 -0400

I am adamantly opposed to DAV:allprop.  In the context of
computed live properties, a client should never blindly ask
for all property values ... it should always first ask for
DAV:propname, and then use the subset that it can use.
The WebDAV versioning extensions explicitly allows a server to
*not* return the versioning properties in response to a
DAV:allprop request, so DAV:propname will be the only reliable
way of obtaining all the properties.  Finally, the fact that
PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND
calls (the first being PROPFIND/DAV:propname) makes DAV:allprop
superfluous (in addition to being inadvisable).

I spoke to Yaron Goland earlier this week (about the ACL spec),
and he believes DAV:allprop should be removed/deprecated as well.
Protocol's are complex enough with important/required features.
A feature that is prone to misuse and is redundant is
a serious error, and should be removed in the next draft.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 12:45 AM
To: [email-masked]
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,   [email-masked]

Jason Crawford/Watson/IBM@[email-masked] on 04/28/2001 02:03:04 PM

Sent by:  [email-masked]

To:   Greg Stein <[email-masked]>
cc:   WebDAV WG <[email-masked]>
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.

---

From: "Dan Brotsky" <[email-masked]>
Date: Thu, 3 May 2001 10:16:53 -0700

I think we might be able to close on this issue if we consider it 
pragmatically:

1. We are having a great deal of difficulty deciding on a single 
semantics for ALLPROP that fits well with the various related specs 
(e.g., delta-V).

2. We already seem to have general agreement on a change in the 
default semantics for ALLPROP (i.e., no depth infinity and the 
default if not specified changes to 0) that's incompatible with the 
current draft (and thus current versions of clients).

 From these two I conclude that there's no way that ALLPROP in the 
next draft is going to have the same semantics as ALLPROP in the last 
draft.  Thus existing clients who use ALLPROP are going to have to be 
rewritten to be compatible with servers going forward.

So we're faced with two alternatives---preserve ALLPROP and change 
clients, or give up on ALLPROP and change clients---which IMHO differ 
very little for client implementors but which are quite different for 
server implementors (the first being harder than the second).

As a server implementor, I vote for option 2: abandon allprop.  As a 
client implementor (which I also am), I can live equally with either 
(as long as it means that servers are CONSISTENT, which is easier 
with option 2).

Are there any client implementors out there who strongly believe that 
changing to a new semantics for ALLPROP is harder for them than just 
doing PROPNAME then PROPFIND?

     dan

P.S. Yes I realize that server implementors who implement 
cross-server COPY and MOVE are also client implementors, and should 
feel free to respond from that perspective! -d.
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: Greg Stein <[email-masked]>
Date: Thu, 3 May 2001 22:59:19 -0700

> DAV:propname, and then use the subset that it can use.

Euh, how does the propname help the computed live prop case? If I fetch all
the names, then fetch the values, then I've still slammed the server with a
bunch of computed props.

Removing allprop does not help this scenario at all.

> way of obtaining all the properties.

When did that go in? That seems to be a direct violation of RFC 2518.

> Finally, the fact that

It is *NOT* trivial. If you want to do a Depth:1, then the client is going
to have to create a union of all the resources' prop names, then do the
fetch for those props. Next, it will need to deal with the 404 that it will
get for the props that weren't available on all resources.

Trivial? Bah.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 4 May 2001 08:21:56 +0200

How about

a) looking again into the proposed PROPFIND extensions to get properties by
namespace (and to suppress specific namespaces), and

b) put for example the deltaV properties into a different namespace?

Julian

> -----Ursprungliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]]Im Auftrag von Greg Stein
> Gesendet: Freitag, 4. Mai 2001 07:59
> An: [email-masked]
> Betreff: Re: Issue: ALLPROP_AND_COMPUTED
>
>