On Fri, Feb 09, 2001 at 05:58:54PM -0800, Fay, Chuck wrote:
>...
> I view retention policy as a workaround or band-aid to the real problem,
> which is not giving core versioning clients an obvious, clean, safe way to
> check in a new version explicitly. Auto-versioning is great for backward
> compatibility, but it's not real versioning in the classical sense of
> checkout, change, checkin. LOCK, PUT, UNLOCK is error-prone, in that
> clients will have to know not to do more than one PUT (for servers that
> don't support storage of intermediate state), to avoid the proliferating
> versions trap. With the alternative, i.e., CHECKOUT/CHECKIN methods, it's
> obvious to the developer that you only get to do one CHECKIN call per
> CHECKOUT. The client just has to check to see if the mutable VCR option is
> supported. If so, it can do intermediate PUTS; if not, it saves all changes
> for the CHECKIN method. How can we deny the core versioning client access
> to CHECKOUT/CHECKIN methods?
You are not suggesting anything new. If the client can avoid intermediate
PUTs, with the intent of sending it during the CHECKIN, then the client
can/should just use a single PUT (with or without locking or checkin/out).
There is no reason to add complexity to the core protocol to support a
trivial (the name of the method that delivers the content) change in the
client.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/