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

Re: BINDing using a weak reference

From: Eric Sedlar <esedlar@us.oracle.com>
Date: Tue, 07 Dec 1999 15:00:44 -0800
Message-ID: <384D919C.9FD474DB@us.oracle.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
CC: w3c-dist-auth@w3.org
Couldn't you make PUT and MKCOL all create strong bindings, and then have weak
BINDings from BIND?  Then you wouldn't have to introduce fake bindings to maintain
persistence?

--Eric

"Geoffrey M. Clemm" wrote:

>    From: "Eric Sedlar" <esedlar@us.oracle.com>
>
>    Can a server implementer build both strong & weak BINDings and only allow
>    cycles in weak bindings?
>
> The current binding spec only defines strong bindings, but if your
> server only allows cycles with weak bindings, you could implement BIND
> by anchoring all resources with a strong binding outside of the URL
> space, and then use weak bindings to implement all BIND operations.
>
>    ccjason@us.ibm.com wrote:
>
>    >      Alternately, a server implementer can disallow cyclic
>    >      bindings from being inserted in the first place, which is
>    >      computationally much cheaper, but which restricts the usefulness of
>    >      BINDings.  (Like the way UNIX restricts hard links to directories).
>    >
>    >    This is now forbidden by the spec.
>    >
>    > Just to clarify.  By "this" Geoff was refering to the possibility of the
>    > server not supporting cycles.  The proposed changes now require servers
>    > to allow cycles to be created.  Geoff was not suggesting anything
>    > regarding hard links to directories.
>
>    Well either you can use the UNIX filesystem to support advanced collections
>    or you can't.  It sounds like the current answer is that you can't.
>
> You can, using the technique described above, i.e. implementing bindings
> as symbolic links into a source tree maintained outside of the URL namespace.
>
> Cheers,
> Geoff
Received on Tuesday, 7 December 1999 18:09:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:52 GMT