Re: BINDing using a weak reference

   From: "Eric Sedlar" <esedlar@us.oracle.com>

   It appears that the authors of the advanced collections spec expect that
   BINDing a resource into a new collection will adjust a reference count
   on the destination, ensuring that the destination resource persists
   until all bindings have been explicitly removed.

As you note below, a mark sweep style algorithm is more appropriate
if you want to do garbage collection (the spec does not require a
server to do any garbage collection).

   The problem with this behavior is dealing with cyclic references.  A
   server implementer may allow cyclic BINDings,

Actually, that wording has been revised to say that a server _must_
implement cycle bindings.

   in which case DELETE
   becomes very expensive, since the server must now validate that there is
   still a valid path to the destination resource from the root, to avoid
   orphaned cycles.

Note that orphaned cycles are not forbidden by the spec, so there is
no requirement to clean up orphaned cycles immediately (e.g. it could
be a weekly garbage collection run).

   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.

   Has any thought been given to a notion of a "weak" binding, which
   doesn't affect persistence?  As long as weak bindings are automatically
   deleted when all of the strong bindings are removed, dangling BINDings
   (the great evil) are avoided.  Especially when a DAV server is
   implementing something like a user space quota, a strong BINDing implies
   that the user creating it wants to maintain storage for the object
   (implying a quota impact), whereas a weak binding would be more like a
   smart bookmark that would follow a web page when moved and disappear if
   that page were removed.

Yes, this was one of the variants discussed, but some of the difficulties
encountered are:
- does a server have to delete a weak binding when the last strong
binding goes away, or can it leave it dangling?
- how can a server ensure that it has write access to all weak bindings
that might need to be deleted when the last strong binding is deleted?
- if a weak binding is left dangling, how is this conveyed to a client?
- does the weak binding track the resource as it moves, or does it
just point at a specific URL?
- what happens if you issue a LOCK against a URL that contained a
weak binding?

So we decided that the complexity of defining and supporting a weak binding
outweighed its benefits.

Cheers,
Geoff

Received on Tuesday, 7 December 1999 11:28:14 UTC