- From: Julian F. Reschke <julian.reschke@greenbytes.de>
- Date: Wed, 6 Jun 2001 23:51:19 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>, "DeltaV" <ietf-dav-versioning@w3.org>
Geoff, last time I checked, MS Office was creating lock-null resources when doing a "save as" on an open document (for which Office already had a lock). Julian > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, June 06, 2001 6:48 PM > To: DeltaV > Subject: RE: Deleting versions > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Are DeltaV servers then not required to support locking at all? > > Correct. > > Lock-null comes along with lock. > > Not from Microsoft (:-). You get locking, but not lock-null's > or depth locking with their IIS WebDAV server. But I agree that > the protocol states that lock-null comes along with lock > (at least, for the current rev of the DAV protocol :-). > > I can (barely) beleive that a server might implement > DeltaV but not support locking. > > Last I heard, Greg had no intentions of implementing locking with > his DeltaV server. We (i.e. Rational) are > likely to initially only support the limited > amount of locking expected by a Microsoft client (i.e. single > resource locking, but no lock-nulls or depth locks). > > In fact, you acknowledge in section 14 that > lock-null may be implemented: > > "Non-version-controlled bindings are not under version control, and > therefore can be added or deleted without checking out the > version-controlled collection. This feature is essential for the > support of lock null resources, since a lock null resource is a > temporary internal member of a collection that should only exist > for the duration of the lock, and should not be captured in the > version history of that collection." > > Yes, it is essential that the DeltaV protocol be compatible with > the locking protocol (if it isn't, please let me know!). But that > doesn't mean it should depend on or be otherwise concerned with it. > To the contrary, ensuring that the versioning protocol is orthogonal > to the locking protocol allows the versioning and locking protocols > to evolve independently. Any explicit statement in the versioning > protocol about the locking protocol risks a conflict with a > statement made in later versions of the locking protocol. > > You're doing what Greg (justly) accused you of and leaving things to be > inferred, or out of the spec entirely. If DeltaV says nothing, then > implementors and servers that do locking and deltaV will be > left without > guidance, on an issue over which the experts (heh) have argued. Their > implementations will differ. > > If an implementor wants to find out about locking, they should go to > the (current version of) the locking protocol. We don't want to rev > the versioning protocol every time the locking protocol changes. So > if there is some subtle locking/versioning interaction, then I agree > that should be identified in the versioning protocol (in particular, > the interaction between lock null resources and versioned collections > is such a case, and therefore is identified). > > So let's get some feedback from the working group: > Who thinks that the ability to apply MKWORKSPACE or MKACTIVITY > is a versioning/locking interaction that merits explicit > mention in the versioning protocol? (I think we can take it > as given that Lisa thinks "yes" and I think "no"). > > As with the DAV:resourcetype thread, I've made all the points > I wanted to make, so I'll leave it up to working group consensus. > > Cheers, > Geoff > >
Received on Wednesday, 6 June 2001 17:52:02 UTC