- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 24 Oct 2001 00:05:13 -0400
- To: ietf-dav-versioning@w3.org
From: Peter Raymond [mailto:Peter.Raymond@merant.com] The deltav draft (section 14.1.1) says that a non version-controlled resource can "eclipse" a version-controlled resource. When the non version-controlled resource is deleted or moved the version-controlled member is exposed. I have a few questions/issues regarding this concept: 1) What happens if a VERSION-CONTROL request is issued on the non version-controlled member that is eclipsing the version-controlled resource? The VERSION-CONTROL request would fail because there already is a version-controlled binding with that name. 2) BASELINE-CONTROL can be issued with a baseline URL in the request body (in order to populate the collection), if there is a non version-controlled resource at the destination whose binding name clashes with the name of a member in the baseline does eclipsing occur? It seems like the same scenario but eclipsing is not defined here. If the server supports versioned collections, it is a regular eclipse. If the server does not, then it is server defined, but for consistency, a baselining server should demonstrate eclipsing behavior, even if it does not support versioned-collections. 3) Why was this defined this way around? Surely the version-controlled member should take precedence over the non version-controlled resource. Moving the non-version-controlled members out of the way to expose the version-controlled members is always possible, while moving a version-controlled member out of the way would require checking out the version-controlled collection. 4) Why was this behaviour defined instead of just failing the UPDATE or MERGE request. This eclipsing behaviour seems odd and it may confuse end users to have their resources masked by some other resource. In client workspace implementations, the non-version-controlled resources are commonly local resources on the client, with only version-controlled resources being stored on the server. This means that a client-workspace server would not know when an UPDATE or MERGE would cause a version-controlled resource to be "eclipsed" by some local resource on the client. The eclipsing functionality provides more consistent behavior for a client designed to work against both client-workspace and server-workspace implementations. In particular, the JSR-147 effort will take advantage of this consistent behavior to define a single client library that unifies interaction with client-workspace and server-workspace servers. Does anyone in the group have any good material explaining the "hows and whys" of eclipsed versions? How did it get into the spec in the first place, was there use cases etc? It was pretty much just the preceding paragraph. Cheers, Geoff
Received on Wednesday, 24 October 2001 00:05:44 UTC