- From: Elias <elias@cse.ucsc.edu>
- Date: Mon, 28 Oct 2002 08:53:33 -0800
- To: w3c-dist-auth@w3c.org
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?
Received on Monday, 28 October 2002 12:02:01 UTC