- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 5 Jul 2001 10:23:53 -0400
- To: DeltaV <ietf-dav-versioning@w3.org>
From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com] > And in the version-controlled collection case, if your > server is sensible, and has the root version of a collection > always be an empty collection, Wait-up<g> I agree with Alan that this is a useful implementation trick to avoid this cascading of root versions, but if the act of creating a new version-controlled collection is very rare, I would rather my versioning server _didn't_ create 'bogus' empty root versions. Introducing an empty root version will have no significant implementation cost, and logically, it is very reasonable to say that every new collection starts out empty, so there is no conceptual problem here with users encountering a root version that is empty. But whether or not an empty root version is "bogus" or "sensible" (:-), the VERSION-CONTROL request is not expensive, because a server can easily leave an "uninitialized" value for any such binding, and only retrieve the root version if the client actually requests a value from an unitialized binding. From the client's perspective, is it any better to have no members of the version-controlled collection (and have to fill them in explicitly), or have the root versions for each member (and likely have to go and update them explicitly)? I accept that for the server it is easier to not create members. The server can use basically the same implementation in either case. The only question is whether it returns some "uninitialized" status when you encounter one of those internal members, or returns the root version. Note that since the client is extremely likely to follow the VERSION-CONTROL request with the appropriate MERGE or UPDATE request, a client won't be encountering these "uninitialized" bindings very often anyway. The members of a version-controlled collection created from a collection version are: (1) the DAV:root-version of the member's history (as proposed) an implementation note should be added to state that severs may chose to make root-versions of versioned collections empty to avoid cascading version-controlled collections. or could just implement them as "uninitialized", and only retrieve the root version if the binding is used before it is explicitly initialized. (2) undefined and have to be explictly created by another version-control/merge request. i.e. when the version-controlled collection is created a PROPFIND depth 1 would answer the internal member names, but attempts to GET them would return 404 Not Found. I considered this, but it introduced what appears to be an unnecessary obscure case (you'd need a DAV:uninitialized-binding-set so that a client could discover what was going on here). Note: I'm not against this, but just thought the current way was simpler. (3) the spec is silent and servers do what they choose. It seems that clients are very likely going to have to go and fix-up all the members anyway so who cares about the initial value. Yes, although I think it is better to define the behavior, so I prefer 1 or 2. (4) forget that I even mentioned "latest" :-( Geoff wrote: > "latest" is a very bad choice ... I believe that selecting > the DAV:root-version is significantly superior. I agree that leaping around across branches is less than optimal, I was stumbing towards Alan's notion of the "linear series" Note that this effectively would bundle "MERGE from activity" into the VERSION-CONTROL request. One of the reasons I resist bundling any of these into the VERSION-CONTROL is that any variant of the MERGE or UPDATE request is reasonable following the VERSION-CONTROL request, so we'd have to give VERSION-CONTROL all the semantics of MERGE and UPDATE if we wanted to do this cleanly. Since I believe that there are several techniques a server can use to make the initial VERSION-CONTROL request very inexpensive (described above) , I think it is cleaner to keep them separate. Cheers, Geoff
Received on Thursday, 5 July 2001 10:24:31 UTC