W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

RE: Deletion semantics for versioning metadata

From: Jim Amsden <jamsden@us.ibm.com>
Date: Tue, 12 Dec 2000 18:40:59 -0500
To: ietf-dav-versioning@w3.org
Message-ID: <OF8100BFAF.875C71E8-ON852569B3.0081F886@raleigh.ibm.com>
Or maybe the post conditions could be treated as preconditions and the
method fail if they're not met. This would let servers that do reference
counts or some such thing, but can't do all that traversal and updates play
too.



I agree that this is a viable implementation trick, and the client would
thereby never see 'invalid pointers' so it would satisfy the MUST protocol.
(I equate it to the protocol saying a resource MUST have a property, and
the server choosing to calculate it on the fly when requested.)
If it looks like a duck, ...

Tim

"Lisa Dusseault" <lisa@xythos.com> on 2000-11-20 05:57:55 PM

Please respond to "Lisa Dusseault" <lisa@xythos.com>

To:   "Clemm, Geoff" <gclemm@rational.com>, ietf-dav-versioning@w3.org
cc:
Subject:  RE: Deletion semantics for versioning metadata

I'd suggest that an implementation "MUST NOT return invalid pointers to
deleted working resources or other dangling pointers".

This leaves the implementation free to clean up on delete, or to clean up
on
request, or in a background process, whatever the implementors prefer.
This
isn't quite "atomic", but it gets the desired behaviour.

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, November 20, 2000 9:36 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Deletion semantics for versioning metadata
>
>
> Ooops.  I answered a totally different question than Tim asked.
> In particular, I answered the question "Is atomic checkin of the
> checkouts against an activity a SHOULD or a MUST".  For that, I
> said "SHOULD".
>
> But the question he *asked* was, "Should the property updates be
> atomic with the delete".  For that I say MUST.
> A dangling reference introduces the possibility that
> the reference will mistakenly be later bound to a different resource,
> which violates the semantics of those properties.  Internally,
> an implementation can create dangling references, but the protocol
> should require that it detect such dangling references and strip
> them out before returning the property value.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Monday, November 20, 2000 8:48 AM
> To: ietf-dav-versioning@w3.org
> Subject: Re: Deletion semantics for versioning metadata
>
>
>
> I believe it should be a SHOULD.  There are a variety of versioning
> repositories that do not provide atomic group checkin behavior, and
> it is a reasonable server value-add to guarantee atomic behavior.
> A client can simply report the error, so it doesn't significantly
> complicate client implementations.
>
> Cheers,
> Geoff
>
>    From: Tim_Ellison@uk.ibm.com
>    Date: Mon, 20 Nov 2000 11:30:16 +0000
>
>
>
>    Is that 'should' a SHOULD or a MUST?
>
>    There are likely servers that cannot achieve an 'atomic delete with
>    multiple resource property updates'.
>
>    Tim
>
>
>    "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on
> 2000-11-19 06:08:03
> PM
>
>    Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
>
>    To:   ietf-dav-versioning@w3.org
>    cc:
>    Subject:  Deletion semantics for versioning metadata
>
>
>    Greg has asked that we clarify the results of deleting things
>    like working resources, versions, version histories, etc.
>
>    I believe it is sufficient for us to say that if a server allows you
>    to delete such a resource, that all the versioning properties of other
>    resources that refer to that resource should be updated to no longer
>    refer to the deleted resource (I'd probably enumerate those properties
>    to make sure there is no misunderstanding).
>
>    Any objections?
>
>    Cheers,
>    Geoff
Received on Wednesday, 13 December 2000 10:55:53 GMT

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