RE: BIND vs. non-movable resources in RFC3253

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Elias Sinderson
> Sent: Wednesday, October 30, 2002 11:49 PM
> To: Clemm, Geoff
> Cc: 'w3c-dist-auth@w3.org'
> Subject: Re: BIND vs. non-movable resources in RFC3253
>
>
> ...
>
> [...] 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?
> Recursive operations such as a depth infinity MOVE/COPY/PROPFIND will have
> problems if there is a cycle. I see two possible alternatives to address
> this problem:
> a) model cyclic relationships as properties or
> b) disallow following links during recursive operations in the  same way
that
> a filesystem does.

A binding isn't a link. Filesystems that support the equivalent of bindings
(hard links) have the same problem. Programs that do recursive operations
need special treatment, that is:

- avoid getting into loops when there are multiple bindings to a collection
(the solution being to keep track of inode numbers that were visited) (*)
- optionally special-case multiple bindings to the same resource (I think
"cpio" can do that, but "tar" doesn't)

(*) In a Unix filesystem,  "." is a binding to the current directory, and
".." is a binding to the parent directory. If you do a "ls -l", you'll the
number of hard links to a file/folder, and the number of hard links for a
folder always always is something like 2 + the number of direct child
collections.

> [...] 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.  [...]
> I have no problem with the creation of cyclic bindings. My primary concern
> is that the server should not be required to detect the existence of a
> cycle. Since there is no way to avoid the creation of cyclic bindings in a
> versioned collection context, option (a) won't buy us anything, so option
> (b) seems to be the only alternative. Is it reasonable to specify that
> recursive operations treat bindings differently than other resources?

No. There is no difference (at least not in the general case, your
implementation may vary :-).


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 31 October 2002 03:46:42 UTC