Re: BINDing using a weak reference

   "Geoffrey M. Clemm" wrote:
   Why not just add a "deleted" attribute to a resource, set this to
   be "true" when a resource is deleted, and then automatically add
   "!deleted" to search queries?

   From: "Eric Sedlar" <esedlar@us.oracle.com>
   If you have an orphaned cycle, the reference count doesn't get
   decremented to zero, so you don't know to set a deleted flag.

Perhaps my choice of name for the flag was misleading.  Let's
call it the "hidden" flag, instead of the "deleted" flag.

My point wasn't that a hidden flag solves the problem of doing garbage
collection, but rather that you can use the hidden flag to give a
client the ability to say "this resource should no longer appear in
searches".  If your server wants to classify certain bindings as
"strong" (e.g. those created by PUT and MKCOL) and other bindings as
"weak" (e.g. those created by BIND), and then automatically set the
hidden flag on a whole tree of resources when that "strong" binding is
deleted, it is free to do so.

   The problem with WebDAV BINDings as currently spec'ed, as well as UNIX
   hard links, is that they have both navigation and persistence
   semantics.  The reason people want to create cycles of BINDings /
   links is for navigational reasons, not for persistence reasons.   If
   you have a "smart" weak link that follows the referenced object and is
   removed when the referenced object is removed, you have all the
   functionality that most use cases require.

I agree that there are some relationships that the user wants to use
to imply persistence, and others where the user only wants to get
navigation.  It is also true that WebDAV bindings are specifically
designed for use when the user wants to imply persistence.

If you want a link that does not imply persistence, you do have
"redirect references" at your disposal.  Although they do not have
exactly the semantics you describe, they should let you do what you
want with with weak bindings.  In particular, they do not have any
implication of persistence, but they do allow navigation.

The main differences between your weak bindings and redirect
references is that the client is responsible for doing more of the
work.  In particular, the client must make a second request to get to
the destination, and the client must delete the link if it doesn't
like it dangling.  Redirect references were defined this way to
support cross-server references (where it is unlikely that a server
would be able to know about, much less delete, all the references
into it from other servers).

Cheers,
Geoff

Received on Friday, 10 December 1999 10:39:35 UTC