Subject: RE: Issue: ALLPROP_AND_COMPUTED

From: [email-masked]
Date: Sat, 5 May 2001 00:02:04 +0100

I agree with Lisa.

Regards,

Tim Ellison
-------- Original Message --------
"Lisa Dusseault" <[email-masked]> wrote:

> 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?

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: "Clemm, Geoff" <[email-masked]>
Date: Sat, 5 May 2001 01:49:29 -0400

From: Greg Stein [mailto:[email-masked]]

   > I have to agree that [allowing a server to not return versioning
   > properties with DAV:allprop] 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?

   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.

Since this topic was discussed at length at the last IETF 
DeltaV meeting, and then reported to this mailing list in
the official minutes for that meeting, I'm not sure that
"truly a stealth action" is either a fair or accurate
description of the process.

Since the deltav properties cannot be understood in their raw form by
a user, nor (for the most part) can they be updated by a PROPATCH,
Lisa's comments apply, and it would be pointless for a client to
retrieve them if that client does not explicitly understand their
semantics (in which case, it can ask for them explicitly).

Cheers,
Geoff

---

From: "Jim Amsden" <[email-masked]>
Date: Sun, 6 May 2001 09:16:34 -0400

Greg (and Jason seems to agree):

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)

I also agree, but think the default should probably be changed to depth 0.
Althought clients are free to deal with that too. DAV4J's
Resource.getProperties() method uses a depth 0 default in its marshalling.
It doesn't really matter what the protocol specifies. Clients can use what
they want. allprop is just one option for getting properties. If servers
are slow or fail on it, client writers will discover this and adjust
accordingly. I don't think there's any need for the protocol to try to
solve it any further. Some servers can return all the properties pretty
fast. As slow as the DAV4J server is on most operations, it can return all
the properties pretty fast since they're all in a single XML document.
Depth infinity isn't that slow either, but their might be a lot of files
returned!

---

From: "Jim Amsden" <[email-masked]>
Date: Sun, 6 May 2001 16:08:24 -0400

Geoff says:

Having clients "discover and adjust" is not a good technique
for achieving interoperability.  The fact that
DAV4J ignores the 2518 requirement
that by default a PROPFIND MUST be DAV:allprop, is a good
example of the interoperability problems that arise when
the protocol makes a poor choice of exposing functionality.
A client writer would need to be aware of the various
"variations from the protocol" that have been chosen
by various server implementors (e.g. returning "errors"
on requests that the server feels are "too expensive"),
and then try a sequence of alternative requests to get the
desired result.

This is not really an interoperability issue unless servers routinely fail
allprop requests. I don't think the protocol anticipate all the policies of
clients might choose to use in requests. That's like saying all distributed
object applications that make a lot of fine-grained remote procedure calls
should be prevented from doing so by redesigning RPC protocols so only some
new kind of course-grained service calls can be made.

DAV4J does not introduce an interoperability problem with its use of
Resource.getProperties(). The protocol on the wire is DAV compliant. This
(client) method simply marshalls its default depth as 0 instead of
infinity. If you want infinity, you need to say so. The DAV4J server is
unaware of this convention, and if it gets a PROPFIND without a depth
header, it does depth infinity.

I'm still inclined to leave allprop alone, and just not use it, or use it
very carefully, in any clients I might write. The DAV4J cross-server copy
does rely in allprop to copy the resource properties.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 6 May 2001 17:46:50 -0400

Oops.  I meant to say "ignores the 2518 requirement
that by default a PROPFIND must be Depth:infinity".

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Sunday, May 06, 2001 10:27 AM
To: [email-masked]
Subject: RE: Issue: ALLPROP_AND_COMPUTED

I personally would like to be a bit more proactive than
"let's wait until it breaks before worrying about it".
By then, all the broken, non-interoperable clients and
servers have been deployed, and its too late for a clean
or simple fix.

The fact that DAV:allprop can be efficiently implemented
by a server that supports only the 2518 properties and the
relatively few number of dead properties that clients
create these days is not the problem.  It is the fact that
large numbers of expensive to compute properties are currently
being defined, both in the protocol and as custom properties,
that raises the concern.

Cheers,
Geoff