- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sat, 6 Jan 2001 00:17:13 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "Lisa Dusseault" <lisa@xythos.com> What it seems you're trying to do is make the server models for mutable and immutable versioning interoperate. However, I don't think that's necessary. For interoperability, we only need *clients* to be able to understand what the server is doing. If an option is something that is just passed on to the user, like "should I have a MERGE operation in the menu", then it's reasonable to expect client implementors to deal with it. If it's something as fundamental as "can I count on the resource at this URL never changing in value" (which affects caching, whether you use it in delta update requests, whether you can store it in dead properties as a reliable reference, etc), then it is unlikely that a client will be written to handle both ways. If we didn't have an interoperable alternative, I'd be inclined to let it go, but the "delete predecessor on checkin" appears to give us the interoperability we need for a single client to (easily) work consistently against both kinds of servers. We already know that clients will have to be able to find out if servers support mutability or not; if they do, it's not that hard for the client to have a slightly different model of what's going on. Any client developers want to chime in here? With the "delete predecessor" approach, a client will not have to find out if a server supports mutability, because the two models will be consistent. In what way is the "mutable version option" incompatible with merging, baselines, or activities? For merging, when you merge an ancestor into one of its descendants, you just get the descendant, because you know that all changes in the ancestor have been carried forward into the descendant. If you let the ancestor be modified after the descendant is created, this breaks this semantics. If on the other hand, modifying the ancestor always creates a new version URL, then the system will not think that the modified version is an ancestor, and will know that the two versions will need to be merged. Similarly, for activities, you can count on the "latest" version in an activity as containing all the changes from earlier versions in that activity, but this semantic is broken if you can modify earlier versions without generating a new version URL. Finally, baseline implementations depend on the fact that you can capture the state of a collection by remembering the version URL's for the versions in that collection. If you can modify a version, this list of version URL's will no longer capture that state of the collection (you would have to actually store the contents of each member). Normally I wouldn't propose two such divergent server models, but in this case I'm coming to believe that the document versioning model is almost incompatible with the code versioning model. They might not be able to coexist on the same server, or at least in the same namespace. Yes, then we've pretty much given up on interoperability (you basically have to write two clients). I'd like to see what is wrong with the delete predecessor semantic before giving up. Cheers, Geoff
Received on Saturday, 6 January 2001 00:18:03 UTC