Yaron's proposals

Just a few comments on what Yaron wrote:

>So, for
>example, the Request-URI of the COPY method must be the destination of
>the copy, not the source. That way the cache will purge responses for
>the destination, which will be changing, rather than the source, which
>will not. The same logic applies to MOVE so long as the Content-Location
>header, set to the source, is included in the response, thus causing the
>source's records to also be purged.

>Documents have structure and it would seem a good thing for DAV to
>expose this structure and make it available for manipulation. As such I
>propose a new Method, STRUCTURE. When executed on a resource this method
>will return a description of the structure of the document.

The first comment is syntactical and clearly minor. I understand that HTTP
*methods* are actions, and therefore grammatically they are verbs, while
*headers* are attributes, and therefore adjectives or nouns. Furthermore,
the parameter of the method should be the grammatical object of the verb. I
may have read it somewhere, or maybe I am just inventing it at the moment.
It seems plausible, though.

Therefore, STRUCTURE, COPY and MOVE are not appropriate, and should be used
something like GET_STRUCTURE, COPY_TO and MOVE_TO instead.

---

Also, about STRUCTURE (or GET_STRUCTURE): it seems to me that item 5.9.2.7
of the specification document refers to something that can be generalized
to what you mention as the STRUCTURE command:

>5.9.2.7. A way to retrieve the complete version topology for a version graph.
>There should be a way to retrieve information about all members of a
>version graph. The format for this information must be standardized so that
>the basic information can be used by all clients. Other specialized
>formats should be accomodated, for servers and clients that require
>information that cannot be included in the standard topology.

By appropriately defining the "version topology" of a version graph as one
of the ways you can structure a complex document, the requirement for
version topology is exactly covered by the STRUCTURE command.

----

>The previous scenarios, however, are safely dealt with through a
>combination of atomic checkout and the UNCHECKOUT method. The checkouts
>prevent alteration to the resources while the system is being updated
>and in the worst case, if the system is left in an inconsistent state,
>UNCHECKOUT can be used to restore it.

It seems to me (and I have mentioned the fact already in the past) that
RELEASE already covers the need for the uncheckout method.

Furthermore I frankly can't understand the problems you are mentioning with
this discussion about atomicity. Inconsistencies are not created by
non-atomic updates, but by non-atomic locks.

We should require that, both before AND after a new version of a resource
is PUT back on the server, the server continues to respond to a request for
a locked resource either with an error if the lock is read-write, or with
the old version if it is a write-only lock, *until the lock is released.*
This is not cause for inconsistencies, and allows slow or piecemail updates
to complex resources without problems.

Therefore LOCK and UNLOCK should allow the specification of complex
resources, or list of resources, and guarantee atomicity in the granting
and releasing of the locks. This was already discussed and required in the
specification document:

>5.3.1.2. Multi-Resource Locking. It must be possible to take out a
>lock on multiple resources in the same action, and this locking
>operation must be atomic across these resources.

, if of course we are assuming that multiple unlock is atomic as well.

Therefore I don't see the need for CHECKOUT and UNCHECKOUT, be they atomic
or not. But maybe I am overlooking something.

---

>The URI namespace is flat. The URL namespace is not. Any URL can be
>decomposed into a base and an extension. This provides the mechanism to
>build up hierarchies. This hierarchy also provides the mechanism to
>present arbitrary structure. This makes Mr. Woodhouse's mime multipart
>extensions unnecessary as the same hierarchical structure can be built
>with URLs. However another mechanism will be necessary for more generic
>URIs. My recommendation, given that currently the only URI widely
>deployed is URLs, is that we adopt the PUT convention for URLs and leave
>the definition of a more generic mechanism for URIs to a future group.

Now I really can't understand. I defended with my blood the hypothesis of
URL-mangling for the specification of versions of resources, and everybody,
including you, jumped at my throat and said that it was impossible.

And now you are proposing a method that mangles URLs, works only with URLs
and not with URIs, relies on the hierarchical structure of the URLs, and is
clearly a mould from directories in file systems, thereby casting in stone
the equivalence between structured documents and server directories?

Fabio

Received on Wednesday, 19 March 1997 04:58:59 UTC