RE: More on ordered collections

I agree there's little we can do about the safe-save algorithms that use
MOVE, sadly.  In fact, the correctest behavior for MOVE is probably, as
with version histories, to retain the source resource's ordering
position if a destination is overwritten.

However, if a destination is not being overwritten, then shouldn't the
MOVE (the rename) preserve ordering?

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> Sent: Monday, April 07, 2003 3:53 PM
> To: Clemm, Geoff; 'Webdav WG'
> Subject: RE: More on ordered collections 
> 
> 
> 
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Tuesday, April 08, 2003 12:19 AM
> > To: 'Webdav WG'
> > Subject: RE: More on ordered collections
> >
> >
> >
> > One thing that I would suggest is to never try to define 
> semantics for
> > both COPY and MOVE at the same time (they have radically different
> > semantics, in spite of what 2518 incorrectly implies, as 
> acknowledged
> > by the authors of 2518 :-).  In particular, in the following
> > discussion, what Lisa says is true for COPY while what 
> Julian says is
> > true for MOVE.  In particular:
> >
> >    > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> >    > >
> >    > > If I MOVE or COPY a resource into a collection, overwriting
> >    > > a resource that has an ordering position, is that ordering
> >    > > position (of the destination) preserved?  Usually not, as
> >    > > RFC2518 defines an Overwrite to be implicitly DELETE the
> >    > > target.
> 
> That's why I wrote *usually* here.
> 
> > I believe that we have consensus that 2518 is wrong here
> > (this is explicitly pointed out in 3253) and that Overwrite is
> > only a DELETE for MOVE, not for COPY.
> 
> That would be good. Do we? Anyway, this should be clarified 
> in RFC2518bis.
> 
> >    > From: Lisa Dusseault
> >    >
> >    > No, I disagree with this.  Overwriting a regular resource does
> >    > not reset all the live properties.  For example, it would be
> >    > pretty disastrous for the ACL property to be reset every time a
> >    > resource is overwritten.
> >
> > Here Lisa is talking about COPY behavior.
> >
> >    From: Julian Reschke [mailto:julian.reschke@gmx.de]
> >
> >    If you do that using a MOVE? I *really strongly* 
> disagree. ACLs are
> >    properties of a resource, not of it's binding/URL. MOVEing a
> >    resource MUST move it's ACL with it, overwriting the target
> >    resource's ACLs.
> >
> > And here Julian is responding with MOVE behavior.
> 
> That *may* be the source for the confusion.
> 
> However I've got the impression that Lisa would like servers to better
> support the following request chain ("safe delete"):
> 
> GET A
> PUT A.bak
> MOVE A.bak -> A
> 
> or similarily
> 
> GET A
> MOVE A -> A.bak
> PUT A
> DELETE A.bak
> 
> Under this scenario, a resource would usually lose it's 
> ordering position.
> However, it would also lose it's version history and it's 
> ACL, so I fail to
> see why this would be a specific problem with the ordering spec.
> 
> However, if the client would issue these requests:
> 
> GET A
> PUT A.bak
> COPY A.bak A
> DELETE A.bak
> 
> and the server conforms to the RFC3253 COPY semantics, there 
> wouldn't be any
> problem with ordering, ACLs or version history (the ordering spec just
> "inherits" from the server's view of what COPY/Overwrite means).
> 
> So if at the end of the day we agree that COPY should always 
> have RFC3253
> sematics, I'm all for it :-) I just didn't want the ordering 
> spec to require
> a specific model.
> 
> 
> Julian
> 
> 
> P.S.: these "safe delete" scenarios obviously can become 
> problematic if the
> client doesn't properly handle dead properties.
> 
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
>

Received on Monday, 7 April 2003 20:29:20 UTC