W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

RE: BIND vs. non-movable resources in RFC3253

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 31 Oct 2002 09:46:00 +0100
To: <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEDBFLAA.julian.reschke@gmx.de>

> 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
> 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

> [...] 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:27 UTC