RE: Bindings, Locks, and MOVE

That the spec needs to address the issue of cross-server anything indicates
that the specification is fundamentally broken and needs to be re-written.
The spec should not need to address these issues at all. Rather it should
provide a well defined start and end state. It is up to the server to figure
out what that means in application. I suspect y'all have taken a serious
wrong term somewhere.

		Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Sat, September 04, 1999 5:57 PM
> To: jamsden@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Bindings, Locks, and MOVE
> 
> 
>    From: jamsden@us.ibm.com
> 
>    DAV4J does do cross server COPY and MOVE. This is an important
>    function required to support publishing web applications. 
> DAV4J does
>    it by reusing GET/PROPFIND and PUT/PROPPATCH (followed by DELETE if
>    MOVE).
> 
> Let me modify Greg's question just a bit:
> 
> Is anybody going to be implementing cross-server MOVE as anything
> more than a cross-server COPY followed by a DELETE?  The reason
> I ask is that it is a MOVE that has all the tricky interactions
> with multiple bindings and locks, while a COPY is relatively
> straightforward (new resources are created, so bindings and locks
> are not affected).
> 
> In particular, I'd advocate making cross-server COPY's a MUST
> (or at least a SHOULD), while a cross-server MOVE's a MAY
> (or at most a SHOULD).  My main argument against MOVE is that
> unless the "fixup" step that comes between the logical
> "COPY and the MOVE" is well defined (as it is in the
> advanced collection spec), the MOVE semantics is so vague
> as to be useless.
> 
> Then a client that wants the COPY/DELETE form of "MOVE" can just
> issue a COPY followed by a DELETE.
> 
> Cheers,
> Geoff
>

Received on Tuesday, 7 September 1999 20:50:12 UTC