minutes for 12/20 Versioning TeleConf
Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Mon, 20 Dec 1999 15:22:14 -0500
Date: Mon, 20 Dec 1999 15:22:14 -0500
Message-Id: <9912202022.AA07716@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: minutes for 12/20 Versioning TeleConf
There was no agenda for this call, but we had 6 callers anyway
(what a dedicated group :-).
We decided to discuss the new LABEL method.
Currently, it returns 200, 404, and 405 (with the usual interpretation).
This did not have a "bad label" response code.
We needed something to indicate that the label was not a legal segment.
If there were multiple label operations in one LABEL request, we'd need
to identify which segment was bad (and decide whether to do the other
legal label requests or not). Since nobody badly wanted to perform
multiple labeling operations in one LABEL request, we propose to just
allow one label operation (add/delete) in one LABEL request, and return
400 if the label is not a segment.
This raised the issue of whether you can "move" or "delete" a label on
a "locked" revision. After some discussion of when you might or might
not want to, the consensus was that locking "live" properties is going
to be very hard to define in an implementation neutral way, so we
would just punt the issue and say that "locking only affects dead
properties and the body of a resource".
So in this draft of the protocol, we will not be proposing a mechanism
for locking labels, locking successors, etc.
Finally, the issue of "how to support locks for a versioning server"
was briefly raised.
Brad is uncomfortable with the "turn off dynamic version selection for
the lifetime of the lock" approach proposed earlier in this mailing
list. Geoff indicated that supporting versioning unaware locking
clients is very important to some versioning servers, so we needed to
specify some interoperable way for those versioning servers to support
a LOCK request from a versioning unaware client, even if that way is
expensive/complex (i.e. cheap/simple is better, but expensive/complex
is better than being unable to support lock requests at all).
We then agreed put this topic on the agenda for the next versioning
teleconf, which will be on Jan. 10.
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