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

RE: Deletion semantics for versioning metadata

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 20 Nov 2000 09:57:55 -0800
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <NEBBKACLEKPHOGFOCGFDGEJGCAAA.lisa@xythos.com>
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 Monday, 20 November 2000 12:56:28 GMT

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