RE: BIND vs. non-movable resources in RFC3253

Yes, if the "modeling" argument didn't carry the day,
I was planning on falling back on the "too expensive"
argument (:-).

But how does requiring that cyclic relationships be modeled
by properties instead of collection membership solve
anything, other than pushing the burden of cycle detection
onto the client instead of the server?

The problem introduced by cyclic bindings was that
PROPFIND needs to maintain a "visited resource" list,
in order to detect cycles.  For a server that supports 
bindings, maintaining such a list is straightforward
(since the DAV:resourceid property is required).

And even if one believes that modeling cyclic relationships
should be done with properties, in a versioned collection
context, there is no way to
avoid the cyclic binding problem.  A client could
create a collection A, add a collection B to A, add a
collection C to B, move C to be a member of A, and then
move B to be a member of C.  None of the states have
multiple bindings to a resource, much less a cycle binding.
But if a user selects the version of B that contains C,
and the version of C that contains B, they have created
a configuration with a cyclic binding.

Cheers,
Geoff

-----Original Message-----
From: Elias [mailto:elias@cse.ucsc.edu]
Sent: Monday, October 28, 2002 11:54 AM
To: w3c-dist-auth@w3c.org
Subject: Re: BIND vs. non-movable resources in RFC3253



Good morning all,

Perhaps you're already aware of this, but... The detection of cyclic 
bindings is reducable to the problem of finding a Hamiltonian Path in a 
graph, which is NP-Complete. I strongly object to placing any 
requirements upon a server which are NP-Complete problems.

Since detection of cycles is NP-Complete, it shouldn't be a MUST level 
requirement that servers detect them. Perhaps they SHOULD detect them, 
but even that seems too strong for my tastes... It's clear that cycles 
may be caused inadvertently by other namespace operations such as MOVE, 
so disallowing them also has the effect of making a server detect them.

The problem is analogous to that of having cyclic links in the *nix 
filesystem, is it not? Is there any reason we cannot follow the same 
approach taken there? The simplest way to avoid the whole mess is to 
specify that namespace operations do not follow BINDed (bound?) 
resources since they could end up in a cycle...

I'd be interested in seeing a use case for cyclic BINDings that cannot 
be satisfied with the judicious use of properties...


Elias


Julian Reschke wrote:

> [...] I see why a server that *does*
> support cyclic bindings need to signal them upon depth infinity operations
> (-> 506), but why would you want to require support for their creation?
> 
> Actually, I'm tempted to require servers to detect cyclic bindings upon
> creation and to reject those requests. What's the use case for cyclic
> bindings?