Subject: Re: Issue: ALLPROP_AND_COMPUTED

From: "Dan Brotsky" <[email-masked]>
Date: Fri, 4 May 2001 11:33:59 -0700

At 12:45 PM -0400 5/4/01, Jason Crawford wrote:
>As it stands now, I have a mild preference for leaving allprop in.  I'm
>*very* willing to support another position if it will bring us to agreement
>and not do any serious damage.

That was the point I was trying to make (apparently not very well :^) 
in my earlier message.  The problem with leaving ALLPROP in is that 
we're clearly going to be changing its semantics (e.g., forbidding 
depth infinity) so existing clients are likely to stop working and 
will need updates.  Plus leaving it in but changing its semantics may 
mean that existing clients will seem to work but in fact give 
erroneous results.  Plus it means we actually have to *agree* about 
its semantics, which is apparently not going to be easy.

Deprecating it is a much cleaner way to change its semantics: servers 
who wish to can still honor it (keeping old clients working) and 
servers that don't can just refuse it (breaking old clients cleanly). 
Clients who update can go to using PROPNAME/PROPFIND pairs and so 
work against all servers.

I think the only problem with this plan is that folks are worried 
about the extra work clients will have to do to do PROPNAME/PROPFIND 
pairs (with unioning) rather than a simple ALLPROP.  So I ask again 
(as a client implementor who doesn't mind doing this):  are there any 
client-side folks out there who believe the extra work is too 
onerous?  And, if so, do you have clear requirements for what an 
updated ALLPROP needs to do in order to work for you?

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 4 May 2001 14:30:04 -0700

> updated ALLPROP needs to do in order to work for you?

To go a little further than Dan did, I would like to know why a client would
do a propname depth 1, a _union_ of all the properties, and a propfind depth
1.  How would they _ever_ display all these disparate properties?  What,
exactly, is the scenario, and is it known that the scenario would work.

1.  The only working scenario I know of that requires discovery of unknown
properties is the "explore information about this resource" functionality.
E.g. one could imagine using Windows Explorer to right-click on a resource
on a WebDAV server, choose "Properties", then choose the "custom" tag, and
it might want to display even unknown property names there at the user
request.  But I can't see that happening for multiple resources at once.
For a single resource, obviously it doesn't require  doing a union.

Also note that this scenario may not require getting the values of all the
properties -- the display would be simplest if it displayed only the names
of properties, since some properties have long complex XML values, and then
let the user select interesting properties to display the value.

2.  I'll explore the replication scenario as well but it's basically an
unworkable scenario based solely on RFC2518.   That's because property
replication is impossible to do with only standard elements of WebDAV, even
if we did keep allprop.
 - If the client doesn't know what properties exist, it can't know which of
them are dead properties.  It can't replicate live properties.  Replication
would require some way of listing or marking up those properties which can
be replicated safely.
 - If the client DOES know what dead properties it can safely replicate, it
can ask for them explicitly.
 - With the current discussion of getlastmodified in mind, clients can't
know when properties change (unless they rely on a particular WebDAV
implementation).  Thus it's impossible to know when to replicate property
values.
 - The client can do 'propname' and individual specific PROPFIND requests
for each resource if absolutely necessary.  These can be pipelined for
efficiency.  In fact, it may be easier to separate them out and pipeline
them, than it would be to do depth requests and then to have to deal with
the size of a serious depth allprop request.
 - Operating against regular webDAV servers, it's quite possible clients
will discover that serious depth allprop requests won't work.  I wouldn't be
surprised if various resource limitation safeguards programmed into various
WebDAV servers would cut off the response part way through or fail it
completely.

With all these considerations, I do not think replication of properties is
decently possible in RFC2518 without writing serious server and client
protocol extensions.  If these server and client protocol extensions are
being done in order to do replication properly, then surely they will design
something better than allprop anyway.

Lisa

---

From: "Jason Crawford" <[email-masked]>
Date: Fri, 4 May 2001 12:45:49 -0400

<<
I think the key part of Geoff's post is "the subset that it can use".  The
problem with allprop is that it will return all the live properties
irrespective of whether the client is aware of the properties' semantics.
Sometimes this is what the client wants, say if it is naively displaying a
property sheet; but most likely it is not since there is no way for the
client to interpret the values or know if/how they can be changed.
Actually I'd think that property sheet case would be pretty common.  And
removing allprop isn't going to prevent people from doing the same thing...
now with two requests rather than one.  And sometimes for wide directories
it will be difficult to avoid this (suspected) problem even without
ALLPROP.  If this is actually the pivotal concern, I think the best you can
do just warn people of the potential cost that we see of using allprop.
From there on in, let time tell if it's really a problem.  If we discover
it is, let's *really* solves the problem then.  I'm willing to remove
ALLPROP, but it doesn't sound like doing that really would solve the
problem and it's not clear if there is a problem.

> It's the old NRA argument -- allprop doesn't kill servers, clients kill
> servers ;-)
At first I thought that analogy was flawed, but as I think about it, I
think that the situation is analogous.  This discussion seems to have all
of the same aspects.  The differences I see are...

1) I don't think it's clear that there actually is a problem in 2518 that
we need to solve.
2) In 2518, the people that would be vicitimized by the concern are
actually in (more) control over whether they are vulnerable.  (Client
programers can discover that they don't really want all those random
properties and perhaps conclude that it's slowing their response time and
stop using ALLPROP.  I think clients can disconnect if a response is too
long.  And I think servers (with guidance from us) can chose to reject
certain requests if they really feel that they are too expensive.)

<<
I have to agree that it is a stealth action to undermine (the effects of)
allprop.
I'm guessing you're joking, but I'd like to hear why that was put in that
spec.  Was there some issue involved that we haven't mentioned here?

J.

---

From: Greg Stein <[email-masked]>
Date: Fri, 4 May 2001 18:05:39 -0700

On Fri, May 04, 2001 at 12:45:49PM -0400, Jason Crawford wrote:
> now with two requests rather than one.

That is my point exactly. Tossing allprop is not going to affect Geoff's
issue with computed properties.

> And sometimes for wide directories

Right!

> certain requests if they really feel that they are too expensive.)

Yup.

I'd prefer the guidance approach. mod_dav (in its default configuration)
will simply refuse Depth:infinity PROPFIND requests (of any variety). Not
necessarily nice, but that was the approach I took. I'd much rather have a
"recommendation" from the Working Group on how to do that.

> spec.  Was there some issue involved that we haven't mentioned here?

I doubt it was joking. It truly was a stealth action. I've never noticed it
before. Looks like it was in 14.1 and 15 at least.

---------------------

In Lisa's post, she posits some possible scenarios. Here is an *actual*
scenario, today:

Subversion (SVN) (the version control system, which uses DeltaV for its
network protocol) exposes the notion of properties on the resources. The
client can get/set them at will, and they are committed along with content
changes to the repository.

SVN uses a CVS-like model, or "client-side" if you will. The content is
pulled down to the client, edits are made, and at commit time, everything is
pushed back up to the server. (blah blah blah about conflict resolution)

So... when the checkout is performed and content is pulled down to the
client, we need to do a PROPFIND/allprop to fetch all the properties that
may have been attached to the resource. The user can then add/change/delete
the properites, and commit them back.

That allprop is the key, and our actual use scenario.

---------------------

I explained how a propname followed by a fetch was non-trivial for the
client, but Tim said "nah, that's trivial." Sorry, but I have to disagree.
You're talking about a good chunk of code to union all of those names and
their namespaces, assigning prefixes to all of them, generating the new
request with all that data, then parsing through all the results where you
have a mix of 200'd properties and 404'd properties. That is very
non-trivial in my book.

[ and yes: I'm both the client and server implementor ]

Cheers,
-g

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

---

From: Greg Stein <[email-masked]>
Date: Fri, 4 May 2001 18:11:40 -0700

> we're clearly going to be changing its semantics (e.g., forbidding
        ^^^^

"clearly" is not all that clear :-) ... assuming it is left in, then I
believe we'll make some guidance as to how clients should use it, and what
servers can do when they see it. But changing its semantics would be a
backwards-compat bitch.

IMO, we just note that servers are allowed to return errors on
allprop/infinity if they want to (just because, or because they see that it
will be too expensive).

>...
> onerous?

Yes. It is burdensome when the existing specification meets my needs
exactly.

Nobody has yet shown that the existing spec is *broken*. The only thing
raised so far is "it bogs the server when computed props exist" and the
alternative to do a propname/propfind; but the alternative has the *same*
server performance characteristics. And I maintain worse perf from a
systemwide standpoint.

> And, if so, do you have clear requirements for what an 

Personally, I would recommend leaving it just as it is, with a note in the
spec that the server can return <this> error in certain cases. The client
should interpret that as "whoops. we asked too much" and back off to a nicer
algorithm. (and better yet, just start with the nice one)

For my particular scenario, the "fetch by namespace" would be ideal. I could
put all of the SVN user properties into a particular namespace and just
fetch those.

Cheers,
-g

---

From: "Kevin Dyer" <[email-masked]>
Date: Sat, 5 May 2001 11:24:01 -0400

I think everyone on this thread is in agreement.  I would like to offer a

> let the user select interesting properties to display the value.

If one solely thinks about a "WebDAV" client as something like a Windows
Explorer then you're correct.  

But think about the marriage of Collaborative Product Commerce tools ( or PDM ) 
with WebDAV.  Folders and files are nodes in a hierarchical network that have 
complex relationships.  The client is now requesting how to navigate the 
relationships between nodes.  The complex XML values provide the additional 
attributes, alternate or substitute components, and possible T&Cs for digital 
rights to access files or the next node.  Depending on what nodes are returned 
to an initial query the client may have to perform a significant amount of 
ancillary requesting to meet the minimum display requirements.

The server-side of this configuration must walk the thin-line between two extremes
of the WebDAV world.  It must still serve the requests of the minimilist clients 
so that a Windows Explorer or Office integration will still be able to find, display, 
author files and yet service the requests of the more challenging clients.

				Just a different point of view,

						Kevin