- From: Eric Sedlar <Eric.Sedlar@oracle.com>
- Date: Sat, 5 May 2001 12:59:33 -0700
- To: <w3c-dist-auth@w3.org>
Maybe we should examine what it takes to replicate WebDAV servers. I think that this is a general problem people are going to want to address, and I know of several people trying to do this. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, May 04, 2001 10:49 PM > To: w3c-dist-auth@w3.org > Subject: 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 16:06:58 UTC