FW: Circular Bindings

A useful note from Jason.

-----Original Message-----
From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] 
Sent: Friday, August 06, 1999 6:51 PM
To: Slein, Judith A
Subject: Re: Circular Bindings



<JUDY>
Jason also suggested in earlier e-mail that there is really no reason why a
request should fail when it encounters a cycle during Depth: infinity.  For
DELETE, MOVE, COPY, and LOCK if the server can detect the cycle (which is
presumed to be easy), it can do the right thing with it and report success.
For PROPFIND, we could just have the server report 506 for a single response
element whenever it encounters a collection for the second time, and not go
into that collection.
</JUDY>
<JASON>
One other thing that I said was that there are two cases to consider...
 1) if the loop includes the request URI... and
 2) if the loop only includes elements that are pure descendents of
     the request URI.

The same thing goes for the destination URI in a copy.  If the destination
URI
(or more precisely, the "parent" of the destination URI) is not included in
the
loop, the deletion phase of the COPY is pretty easy.  But consider if if the
destination (and it's parent) is in a loop....


/a/b/c/d/b/c/d/b/c/d/....

if /a/b/c/d is the destination, then a deletion is probably also going to
remove
various links and leave us
with /a/b/ before we try to actually begin copying at /a/b/c/d....  but
wait! we
can't copy to /a/b/c/d unless /a/b/c  exists.

Now if /a/b/c is the destination, once again the deletion phase will leave
us
with /a/b/.  And the COPY should work just fine.

Now let's take the above situation and also say that there exists
/e/c/d/b/c/d/b/c/d/...  And let's say the destination is /e/c/d/.  That's
the
same destination resource as in the troublesome first situation, but we are
using a different URI to specify it.   The deletion phase leaves us with
/a/b/
and /e/c/ and the subsequent COPY phase can be pulled off. with much of the
same
result that we would have expected in that first scenario.

Now let's us consider this previous siutation, where there is an /e/c, but
let's
make the destination URI the same as the first situation: /a/b/c/d/.  Once
again, we are left with /a/b and /e/c/ after the deletion phase.  Are we
allowed
to go through with the COPY phase?  The parent resource still exists... but
the
URI that was used to specify it doesn't....  Hmmmm. :-)

Anyway, my point is that if the request URI (or the destination URI) is
included
in a loop, that can pose real problems that aren't as easily resolved as
loops
that reside entirely decendants of request URI.  We should be aware of these
distinctive classes of loops.

Another observations that's not related to loops but that my example reminds
me
of.  In the rfc2518 we say that a COPY performs a implicit delete at the
destination.  That has the possibly unfortunate side effect that if a
portion of
the destination subtree is shared via bindings with another portion of the
URI
space, that sharing is lost.  For that reason down the road I think we
should
have an operation that is much like DOS's XCOPY /s.  I don't want to delay
the
spec now for that.  It can be added later.

BTW, this also reminds me that with AdvColl, it is possible that a portion
of
the source tree and the destination might be common.  And that initial
deletion
phase of the COPY might actually essentially delete a portion of the source
tree.  It's probably a red herring, but it's probably also something we
should
mention in the spec.
</JASON>

Received on Monday, 9 August 1999 09:08:25 UTC