Subject: Re: BINDing using a weak reference

From: [email-masked]
Date: Thu, 9 Dec 1999 03:09:21 -0500

I can tell you
that if most Oracle customers are offered the choice of having a bunch of
great neat content management functionality at the price of decreasing
search performance, they will stick with the search performance.  Nothing
irritates users more than waiting for search results.
On the comment I quoted above...Are we talking about text searches?
You did mention text searches above.
If performance were important,
wouldn't you build an index and just use the index to service queries?
... just like most search systems do?   If you use an index,  the amount
of time users wait for search results is not really relevant to your
point.  The performance will be the same either way.

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 09 Dec 1999 09:27:53 -0800

Of course you will build an index.  That's the problem, because you are
locating the data without traversing the collection hierarchy to find the
data.  Let's say you find a hit using that index.  That item may actually
have been deleted because you have deferred garbage collection, and there is
no way to update the index to remove that item until the actual resource has
been deleted.  If you were traversing the hierarchy as well, you wouldn't
find that item if it would be garbage collected later because there wouldn't
be a path to find it.

--Eric

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 9 Dec 1999 23:55:37 -0500

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?

Cheers,
Geoff

   From: "Eric Sedlar" <[email-masked]>

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 10 Dec 1999 00:12:10 -0800

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.  You don't know what is going to be
deleted until you do a graph traversal.  Let's say we have the following files, ID
= 1 & Id =2.  /a identifies resource 1.  /a/b identifies resource 2.  We bind /a
into /a/b, creating a cycle (I can now get to resource 1 with /a/b/a).  The
refcount on /a is 2 (the BINDing from root and the one from /a/b).  The refcount on
/a/b is 1 (the BINDing from /a).  Now I unlink /a from root. Both resource 1 (the
former /a) and resource 2 (the former /a/b) now have refcounts of 1.  However, both
should be deleted as I now have an orphaned cycle (RFC2518 specifies that deletes
are recursive to infinity).  There is no way to detect this condition without the
garbage collection.  Until the garbage collection runs, resources 1 & 2 will still
show up on hits.

Garbage collection on in-memory objects (like in a Java VM) is bad enough.  Doing
it on disk is incredibly awful.  Many applications find the need to issue lots of
bulk DELETEs (delete *.* in this directory, for example).  Each of these will
require a separate path traversal if you are doing this synchronously.

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.

--Eric

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 10 Dec 1999 10:39:33 -0500

From: "Eric Sedlar" <[email-masked]>
   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

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 10 Dec 1999 11:52:48 -0800

In the example I gave, assuming only strong BINDings as defined in the draft
spec, how would you know to set the hidden flag?  How would the client know
to set it in that case?  My point is that until you do the garbage
collection, you don't know whether or not the object should remain for
future searches.

My suggestions regarding weak BINDings don't address the needs for symbolic
links (or redirect references as you are calling them) in the spec, because
of the cross-server reasons you cite.

I can't do what I want with weak references as long as the spec says that:

1) BINDings must affect persistence
2) BINDings can be cyclic

If the spec just said that BINDings may not dangle (dang it!) but that the
server has a choice of either removing other BINDings (in my case if they
are weak) or affecting the refcount, that would let me do it.  However, it
would be best if the client knew about weak vs. strong references, so that I
don't have to extend the standard to choose a strong vs. weak binding.

--Eric