- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 4 Apr 2001 18:02:15 -0400
- To: ietf-dav-versioning@w3.org
From: Fay, Chuck [mailto:CFay@filenet.com] I'm glad to see from the meeting notes that I wasn't the only one who wondered about Core versus Basic (Core + checkout + fork control). I agree with Mark and Larry that Core is sufficient to implement versioning, and with Eric that some clients will be perfectly happy to deal with Core-level servers. I agree with this as well. So I believe DeltaV should have a package which is just Core. It's important to separate "features" (what we used to call "options") from "packages". The consensus at the meeting was that a server reports its capabilities in the form of a set of features (in the DAV header from an OPTIONS request). In the protocol, we define a small set of feature sets, or "packages", that a server SHOULD support, as a way to simplify the creation of interoperable clients. This means that a server MAY support just the "version-control" feature, but not any of the defined packages. On the other hand, to keep the interoperable client combinatorics in control, we propose to define a small number of "packages" that reflect a set of features that appear to cover the majority of planned implementations. I would not replace Core with Basic. Given that decision, I would rename Basic to avoid the implication that it's the minimum package, or otherwise make it clear that Core is the minimum. Yes, all features require the "version-control" feature, which makes it the logical minimum set of versioning features. But it is still reasonable to say that the smallest defined "package" consists of more than that logical minimum set of versioning features. Although Lisa has recently posted a suggestion that we actually return package names in OPTIONS, rather than feature names, I do not agree with this suggestion, and this suggestion was not supported by the working group in Minneapolis. I disagree with Geoff and JimW that adding checkout and fork control is low cost for any server wishing to be DeltaV-compliant. The minutes are a bit misleading there. I agreed that it is reasonable to have checkout and fork-control in the smallest defined "package", but I did not agree that a server have to support this in order to advertise any DeltaV support. To the contrary, I believe as stated above, namely that a server MAY just support the "version-control" feature (which does not have CHECKOUT). Recall that checkout requires mutable VCRs on the server which hold intermediate state between checkout and checkin, whereas Core has no such requirement. I agree. Core allows all server-resident resources to be immutable, which is arguably a more consistent model than the mixed model with checkout (mutable checked-out VCRs, everything else immutable). More "consistent"? I probably wouldn't go that far ... if you want to have consistent property/content, unless you can come up with a way of updating both in one HTTP request, you'll be creating inconsistent immutable states on the server, which doesn't sound like a good thing to me. This is why although I agree that a server MAY just support the version-control feature, it SHOULD support CHECKOUT. For existing versioning servers that disallow mutable objects, the cost of supporting checkout is non-trivial, because code would have to be written to subvert the fundamental design of the server. I agree. Cheers, Geoff
Received on Wednesday, 4 April 2001 18:01:25 UTC