Re: BINDing using a weak reference

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

----- Original Message -----
From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Friday, December 10, 1999 7:39 AM
Subject: 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 14:52:21 UTC