RE: Issue: ALLPROP_AND_COMPUTED

I agree with Tim, Lisa, and Dan (:-).

Cheers,
Geoff

-----Original Message-----
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

I agree with Lisa.

Regards,

Tim Ellison
-------- Original Message --------
"Lisa Dusseault" <lisa@xythos.com> 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

Received on Saturday, 5 May 2001 01:50:13 UTC