- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Thu, 5 Jul 2001 16:07:31 +0100
- To: DeltaV <ietf-dav-versioning@w3.org>
"Clemm, Geoff" <gclemm@rational.com> wrote: > 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. I disagree that users would reasonably expect to see an empty collection version. I only expect to see versions that capture states that I'm interested in (the initial empty state is not one of them). But, other than the fact that I wouldn't want to rely on it, that is something of a digression... > 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. I agree that the server can be lazy, the question is what value should a client see if it looked? > 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. I agree that is the issue, unless we identify another candidate. > 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. Agreed. > 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. I don't want to get too much into implementation at this stage, though I agree with your observation. The question at hand is whether the spec should be changed (as proposed) to define the default value of such a binding. If we believe that the client will always fix-up the binding anyway the answer may as well be 'no'. > (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. I tend to agree. Although we did have it this way months ago, I think it is likely to be confusing, so I'd happily rule this option out. > (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. I kinda like this one, but can see the benefit of defining the behavior; it's just too bad that the DAV:root-version is unlikely to be a useful choice for most clients. > (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. I agree. > 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. I agree that it is cleaner to keep them separate (despite the server implementation). I'm mildly in favor of leaving it undefined, and mildly in favour of making it the DAV:root-version, and strong in favor of selecting the 'right' version <g> (... we could have these revision selection rules that ...hmmm)(joke) Regards, Tim
Received on Thursday, 5 July 2001 11:07:16 UTC