- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sat, 2 Jun 2001 16:23:31 -0400
- To: DeltaV <ietf-dav-versioning@w3.org>
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] "Lisa Dusseault" <lisa@xythos.com> wrote: > Geoff said: > 2. I don't think the issue of a version-controlled-resource with zero > versions is sufficiently addressed. For your convenience, here's the > section from 2518: > ... > A direct read of this paragraph combined with deltaV draft 15 (and your > implication) would indicate that you can't issue a VERSION-CONTROL method > on a lock-null resource. That's bogus. No, that's great!<g> The lock null resource is a nonce concept that is not required by Delta-V. Reading the quoted paragraph with Delta-V gives (IMHO) the correct impression that versioning operations are not allowed on lock null resources. Another reason that we do not require a server to support putting a "null" resource under version control is that some version control systems cannot put a resource under version control until they know what kind of resource it is. For example, a collection often requires a very different kind of version history resource from a text document. > A "write locked null resource" > is there so that the creator can do all the write operations and state > changes they need before making the resource visible to everybody. This isn't true since you cannot PROPPATCH a lock null resource, and as soon as the first PUT/MKCOL succeeds it is no longer in the lock-null state -- so there really is no set of state changes that can be applied to a lock null resource. I agree. > So, I suggest that VERSION-CONTROL (and perhaps other methods > like CHECKOUT, MKWORKSPACE...) should be explicitly allowed by > DeltaV to be done on write locked null resources, and that the > spec define a precondition that can be returned if the server > decides not to allow operations on write-lock resources. I see no argument for VERSION-CONTROL or CHECKOUT, but MKWORKSPACE is a more likely candidate since it is akin to MKCOL. This would obviously require a modification to RFC2518's statement that the lock null resource MUST fail methods that are not in the named list. I agree that it does at least make sense to allow MKWORKSPACE (and MKACTIVITY) to apply to lock null resources, but since creating a lock null resource before issuing the MKWORKSPACE provides little or no benefit, and since the concept of a lock null resource is so bogus (:-), I would prefer not mentioning lock null resources in the versioning protocol unless a pressing need to do so is identified. Cheers, Geoff
Received on Saturday, 2 June 2001 16:24:09 UTC