Notes from Versioning TeleConf call, 3/29/99
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 30 Mar 1999 00:30:35 -0500
Date: Tue, 30 Mar 1999 00:30:35 -0500
Message-Id: <9903300530.AA23679@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: Notes from Versioning TeleConf call, 3/29/99
Issue-1: Is a "snapshot" (a configuration revision) just created by
a "snapshot" operation (or can it be checked-out, modified, and then
checked-in)?
Argument for: more flexible.
Argument against: more difficult to implement for the server.
Argument against: duplicates workspace revision-selection-rule
functionality in a less flexible way.
Decision: No resolution (issue just raised with minimal discussion).
Issue-2: Specifying Checkout/Checkin policy
This issue eventually was divided into three questions:
1: Can you specify checkout policy (e.g. single checkout) at CHECKOUT time ?
Argument for no on (1): Clients can just check themselves whether the
checkout policy is being satisfied.
Argument for yes on (1): Some checkout policy decisions must be made
atomically (e.g. single checkout). The state of the server could change
between the time a client checks for checkout policy information, and the
time the client issues the checkout. In this case, the client would have
to issue the state query again, to make sure it wasn't violated, and then
undo the checkout if it was violated.
2: Can you specify checkin policy at CHECKOUT time (e.g. intent to checkin
overwrite)?
Argument for no on (2): Clients can just check themselves whether the
checkin policy would be satisfied.
Argument for yes on (2): Decreases number of requests that must be
made by the client.
3: If so, can you store checkin policy on the working resource for use
at checkin time?
Argument for no on (3): This should be part of checkin, not part
of the state of the working resource.
Argument for yes on (3): This allows to client to persist known information
on the server in an interoperable way, rather than requiring the user to
remember it.
Counter-Argument: The user might forget what was specified
Counter-Counter-Argument: A forgetful user can chose to not store
this information on the working resource.
Decision: Defer decision until a concrete protocol can be reviewed
to determine which approach is simpler.
Issue-3:
Do the creation and modification time properties suffice for clients
and servers that want a "temporal history" report (as opposed to a
checkin/out history report)?
The concern was raised that this would be a problem for distributed
versioned resources with clock skew. The response was that there
was no known better alternative to do distributed temporal ordering,
and that there are effective mechanisms for minimizing clock skew.
Decision: Time properties do suffice.
Issue-4:
Are the level-2 VersionedResourceID's (URN's) needed at level-1?
Decision: They are not required at level-1, but that a level-1
server is free to support them in their level-2 form.
Note: This issue was raised by Brad, and he could not make the
conference call, so Brad may want to re-open the issue.
Cheers,
Geoff
--
Geoffrey M. Clemm
Chief Engineer, Configuration Management Business Unit
Rational Software Corporation
(781) 676-2684 geoffrey.clemm@rational.com http://www.rational.com