W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Deleting versions

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>
Message-ID: <JIEGINCHMLABHJBIGKBCAEGHCGAA.julian.reschke@greenbytes.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT