- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sun, 7 Jan 2001 22:13:09 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Edgar@EdgarSchwarz.de I'm very confused. Either you misunderstood something or you must explain it in more detail because I don't understand the connections between my post and most of your reply. Could you check whether there are any typos in your use of "ismutable" and "immutable" ? Yes, I was thinking "immutable", but sometimes wrote "ismutable". Sorry about that! (Don't you hate it when people post things without proofreading them? :-) > Edgar's proposal is basically to keep the current "mutable version" > semantics, but to require that once "ismutable" is set to "true", > it cannot be set back to "false". I would still say it's more but only if you exchange "true" and "false". Yes, or exchange "ismutable" with "immutable". > mutable versions. I believe that any sensible server will refuse > to let you set the "immutable" flag on any version with a human > meaningful name, since over time, this would result in the limited > number of human meaningful names being "used up" by immutable > version URL's. I don't understand. I don't want to make a "human meaningful name" immutable. I just want to make a version immutable. I didn't want to say anything about the topic of meaningful names. That's another matter. But the people that have been lobbying for mutable versions and "reuse of version URL's" (Mark and Lisa) want them to have human meaningful names. So a solution needs to deal with both issues. Why do you think my proposal would use up version URL's ? If the folks that want to support mutable versions will want them to have human meaningful names, then if those mutable versions with human meaningful names are made immutable, then that human meaningful name can never be used for anything else. This is how version URL's would use up human meaningful names over time (if a server let you make a mutable version immutable). Is this different from when all versions are "immutable" like when you don't allow mutable versions ? Nobody who is supporting immutable versions has asked or expected them to have human meaningful names. To the contrary, I believe everyone that supports immutable versions agrees that you have to add some kind of GUID'ish string to the name, to avoid using up "meaningful" names. > The key point here is that a "stable name" is incompatible with a > "human meaningful name", so any attempt to unify "resources with > stable names" and "resources with human meaningful names" will > never succeed. I didn't think I was talking about what you seem to understand, please elaborate. Does the above clarify my point? (Typing "ismutable" when I meant "immutable" couldn't have helped much in making my point understandable :-). > So it is unlikely that anybody was ever going to support the > "ismutable" transition from "false" to "true" anyway. Fine with me. That's forbidden. Replace that with "It is unlikely that anybody was ever going to support the "immutable" transition from "false" to "true" anyway. (And the reason was that those supporting mutable versions want to give them human meaningful names, so if the mutable version became immutable, that human meaningful name would be permanently allocated to that version. BTW, my goal was to add limited mutability to core versioning while keeping the stability of versions which is the key concept for baselines and reproducability. We already had that ... what we didn't have was interoperability between clients that required mutable version functionality and servers that would only be providing immutable versions, or between clients that required immutable versioning functionality and servers that would only be providing mutable versions. But the "variant" proposal does give us that, since it uses existing mutable behavior (version-controlled resources) to provide the functionality needed for "mutable versions". Cheers, Geoff
Received on Sunday, 7 January 2001 22:14:01 UTC