RE: Yaron's proposals

Fabio, I unfortunately do not have the grammatical vocabulary to explain
why your analysis is incorrect. Rather I will have to refer you to
current practice which provides us with methods such as PUT, rather than
PUT_TO, and GET, rather than GET_FROM.

Re: 5.9.2.7 - This mechanism works through a link and declares its
structure through a Web Collection. In fact collections were originally
implemented using the same mechanism. However implementation experience
has demonstrated that having to resolve the link in order to get to the
data is expensive. It is possible to use a convenience method such as
GETLINKVAL but having an explicit STRUCTURE method makes the use of the
mechanism easier to understand. Besides I expect many servers to not
want to implement, the generic method, GETLINKVAL but to definitely want
to implement, the more specific method, STRUCTURE.

As I have never heard of the RELEASE method I can not address its
functionality as it applies to UNCHECKOUT.

If a client looses its connection before it has finished all of its
updates then the site is stuck. The client's CHECKOUTs cannot be
released because this would expose the website in an inconsistent state.
Only an UNCHECKOUT method allows the web site to be reset to a
consistent state.

URL Mangling - Please refer to the HTTP 1.1 specification and its
discussion of relative URLs. You will find the functionality I am
referring to defined there.

		Yaron

> -----Original Message-----
> From:	Fabio Vitali [SMTP:fabio@cs.unibo.it]
> Sent:	Tuesday, March 18, 1997 5:19 PM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	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 05:02:56 UTC