RE: Issue: ALLPROP_AND_COMPUTED

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