Re: Locking a Resource or Locking a URL?

>*snip* (the full message can be found at:
>http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0230.html)
>
>The authoring team for Advanced Collections has debated this approach, and
>decided not to adopt it for the following reasons:
>
>1) It would require an extra discovery step to determine where the
>authorable namespace mapping resource is found.  So, instead of being able
>to directly say "create binding at B to A" by issuing a method directly to
>URL B, first a client would need to query a property (most likely on its
>containing collection) to discover the authoring location, then go modify
>the authoring location.

More likely, it would already know what the mapping resource is because
it has already retrieved the collection listing, which is certainly capable
of indicating that the name is a binding.  In any case, such a discovery
step is not an undue burden given the need for robustness rather than speed.

>2) It would either require extra methods to specifically modify the
>authorable mapping resource (ADD_MAPPING, REMOVE_MAPPING, with the
>consequence of introducing a new type of resource, the mapping resource), or
>it would require the client to understand the syntax (and require the
>protocol to standardize the syntax) of the mapping resource (but at least it
>would be a plain, generic resource).  This would introduce the problem of
>how to handle MOVEs on this resource.

You would have to define a syntax for one possible media type for
exchanging this information, yes.  MOVE is not an issue, since the mapping
resource is either part of the collection or not (i.e., MOVE is rejected
by the server if just the binding is moved, with an indication to edit
the mapping resource instead).

>It would also confuse the definition
>of a collection, since the binding between a URL and a resource would belong
>to more than one resource (the collection and the mapping resource).

No, the collection resource is a product of a server's configuration,
one part of which is the mapping resource.  If this wasn't bidirectional,
the collection would be unable to list its own members.  [I imagine most
implementations would allow at most one specially-named mapping resource
per collection, just as Apache only has at most one .htaccess file per
directory.]

The reason I prefer this model is because it is unavoidable in practice.
If it isn't defined this way in WebDAV, then all directory-configurable
servers will have to implement BOTH the trivial bindings of WebDAV and
their own more capable bindings via the indirect configurations.  The
question is whether the collection is able to denote those bindings
within the collection listings, and thus within your precious Save As ...
dialogs, and yet give the client a reasonable indication that it can't
use BIND/UNBIND to author them, leading therefore to an interoperability
requirement.  The existence of directory-configurable bindings far predates
WebDAV, so you should consider this to be a requirement on the manipulation
of http namespaces.  If nothing else, you need to at least have a way of
distinguishing them within the collection.

....Roy

Received on Wednesday, 21 April 1999 22:00:02 UTC