Subject: RE: Bindings, Locks, and MOVE

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Tue, 7 Sep 1999 17:50:03 -0700

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:[email-masked]]
> Sent: Sat, September 04, 1999 5:57 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Bindings, Locks, and MOVE
> 
> 
>    From: [email-masked]
> 
>    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
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 10 Sep 1999 00:42:47 -0400

From: "Yaron Goland (Exchange)" <[email-masked]>

Or it means that the section that talks about the cross-server as
a special case is irrelevant and should be deleted.

   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.

Yes, I heartily agree!  That reference to cross server moves in the spec
always bothered me, but it took this note from Yaron to clarify why it
was so bothersome.

 I suspect y'all have taken a serious wrong term somewhere.

Actually "a wrong term" in this context is quite a good pun,
albeit somewhat recursive and probably unintentional (;-).

I believe that it is sufficient to just delete the sentence that talks
about cross server moves.  If a server can implement it, then fine.
If it can't, it needs nothing in the protocol to indicate that it can
fail the request -- it simply must do so.

So please ignore all my burbling about SHOULD's and MAY's in this
regard (which I've quoted below as a form of self flagellation).
Also, I fully agree with Yaron's point in a different thread that a
MOVE is not a COPY followed by a DELETE (and yes, Yaron, I admit it, I
was laughing while reading that thread :-).  My point below was
intended to be that a COPY followed by a DELETE is *not* a MOVE, it is
a COPY followed by a DELETE.

Cheers,
Geoff