Re: BINDing using a weak reference

<introductory paragraphs from Geoff were cut here...>

Are you assuming that WebDAV servers will generally be standalone repositories, or do
expect existing repositories (e.g. ClearCase, MSExchange, Oracle RDBMS) will implement
WebDAV in addition to other protocols they currently use to access information
therein?  Do you expect WebDAV servers to be only used for managing development
content or also to manage production content?  It would seem like you would want the
broadest audience possible, and that would include existing servers and handling both
development and production content.  If you implementing WebDAV on an existing server
breaks their existing guarantees, they won't be able to support WebDAV, which seems
like an undesirable outcome.

"Geoffrey M. Clemm" wrote:

>
> WebDAV only supports searches that traverse the hierarchical namespace,
> so although I understand your point, it does not apply to WebDAV as it
> is currently defined.  Once the "V" (versioning) is added to WebDAV,
> queries across the entire resource space will probably be rare in any case.
>

It seems to me that the most common type of WebDAV application would be managing
content on a web site, and the most common type of search (as is most common today)
would be the Yahoo-like one box keyword search across the entire resource space, or
perhaps contrained across a certain class of resources, like Amazon's "Search all
books" functionality.  If I want to implement this functionality against a resource
space managed by WebDAV, I'm screwed if I defer garbage collection.

>
>    Also,
>    deferring the garbage collection associated with the unlink breaks the
>    transactional guarantee when people COMMIT their work.
>
> There is no COMMIT functionality in WebDAV, so this would not be an issue.
>

Are you assuming that WebDAV can only be implemented against non-transactional content
repositories?  If so, you should state that in the charter for WebDAV.  I think you
would be unnecessarily restricting the number of vendors interested in WebDAV if you
did this.

>
>    I can give you a perfectly good set of answers about how to deal with weak
>    links.  Oracle built a system that implements weak links and forbids cycles as
>    part of the Internet Filesystem product.  My responses to your issues are
>    included below, marked with <es> </es>.
>
> The set of answers you provide for the Internet Filesystem product
> appear both consistent and very sensible, especially in the context of
> an underlying relational database implementation for the WebDAV store.
>
> Just one comment on the locking issue:
>
>    <es> locking a URL locks the namespace, not the resource.
>
> I assume this only applies to weak bindings (i.e. there must be some
> way to lock the resource itself, so I assume that is done through a
> strong binding?).
>

I'm jumping to conclusions here based on the conversations you have been having with
Yaron Goland.  Given that some applications will want to reserve the entire pathname
when they LOCK it to prevent it from being moved, it seemed like a dichotomy would
have to be introduced where there are two separate types of LOCK operations: one that
locks the name separately from another request that locks the resource it refers to.

>
>    While you have
>    locked the URL containing a weak binding, nobody else can use that set of names
>    in their respective collections.
>
> This sounds very different from WebDAV locks, which prevents
> unauthorized clients from modifying a resource, not from using it.
> Or by "use", did you mean "modify"?
>
> By "set of names", did you mean for example the set of names:
> {"/a/b/c", "/a/b", "/a"} that are relevant for a binding named "/a/b/c"?
>

I meant that the name "a" is reserved in the root collection, the name "b" is reserved
in the "/a" collection, and the name "c" is reserved in the "/a/b" collection.  By
reserved, I meant that no new files could use those names in those collections, nor
rename those names or move those links into another collection.

>
>    The resource the locked URL points to may actually be deleted while
>    the URL to it is locked.   In this case the resource
>    is deleted when the lock is released.  (Think of the lock like an open file
>    descriptor, or in database terms, a snapshot in a read-only transaction that
>    was started when the lock was acquired).  This has the same effect as if
>    someone deleted that resource the instant the lock was released.
>    </es>
>
> This could be hard for a server implement if it didn't have underlying
> transaction support.
>

Well UNIX doesn't go through a lot of hoops to maintain storage for open files.
However, another way to do this is to increase the reference count on the resource by
one for each BINDing and LOCK against the resource.  Why do you think this would be
hard?

>
> Cheers,
> Geoff

--Eric

Received on Tuesday, 7 December 1999 18:06:57 UTC