- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 31 Oct 2002 09:46:00 +0100
- To: <w3c-dist-auth@w3.org>
> 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