- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 14 Jun 2001 17:48:26 -0400
- To: ietf-dav-versioning@w3.org
From: John Hall [mailto:johnhall@evergo.net] A similar issue arises when I bring up the topic of properties. The issue isn't the 'burden on the server' from implementing versioned properties. The issue is customers and users that say "but why on earth would anyone want to do that?". From my personal perspective, as someone who has been using code source control for a decade, I'm close to that position myself. Not fully, since I understand that you folks want that behavior. But with the exception of narrowly defined sets of properites (which ought to be declared) it isn't something I want / need / would use and I'd rather not have my server resoruces devoted to it. From a historical perspective, you only had content (and a few system defined live properties), not dead properties, so you can't use that as an indication one way or another that if you had dead properties, whether you would want them under version control or not. And even if I have a system that wants to version properties, I would *really* object to creating a new version just because a property changed. Based on what usage of dead properties? I'm sure one can imagine some, but they would need to be compelling to complicate the protocol in this way. Surely I'm not the only user in the universe that feels that way. Perhaps someone can come up with a way that you don't have to support which would make the current-checked-in-properties mutable. <!ELEMENT properties-mutable EMPTY> within auto-checkout would do it. There are a variety of interesting meta-information that you would like to say about properties ... mutable version specific dead properties is just one of them. But the consensus of the working group the last time this was discussed was that this needed to be worked out in the context of a general property metadata proposal, and not as a special one-off case for this particular property behavior for the versioning protocol. Consider the following language: An implementation MAY support properties-mutable as a default within auto-checkout. It is DISCOURAGED. Usually you deprecate old functionality that turns out not to have been a good idea, not new functionality (unless you knew from the beginning wasn't a good idea, but then why add it :-). If present, an implementation MUST support removing the element so that clients who do not wish any properties to be mutable may protect themselves against this server option. An implementation MAY NOT allow the element to be set. IF the element is present then the currently checked in versions properties are mutable and may be changed by a PROPPATCH without creating a new version. If the VCR is in an unlocked state, a PROPPATCH will mutably change properties if unlocked-update AND properties-mutable are present. In the locked state, a PROPPATCH will mutably change properties if locked-update AND properties-mutable are present. The auto-version stuff is bad enough without this ... we don't want to make it any worse unless there is a really compelling use case for it. Cheers, Geoff
Received on Thursday, 14 June 2001 17:43:00 UTC