RE: Mutable Versions (was: re-use of version URL's)

What you propose makes it impossible for a core-versioning server to
implement mutable versioning: the server (and clients!) would have to
implement labels as well.

A simpler proposal would be just to have an "ismutable" flag that could
be queried on any resource.  A core-versioning server could treat a
CHECKOUT as creating a new version, whereas a PUT without a CHECKOUT
would alter the current version.

I would support having an "ismutable" flag in CORE, because it is
trivial for a server that does not support mutable versions to set this
always to "false", and vice versa of course.

I've been doing some thinking about his, and I'm about to construct a
mail that outlines how mutability is absolutely necessary in some
situations, and how human-readable version URLs help out in these
situations.  Wait for it... ;)

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
> Clemm
> Sent: Friday, January 05, 2001 8:53 AM
> To: ietf-dav-versioning@w3.org
> Subject: Mutable Versions (was: re-use of version URL's)
>
>
>
>    From: Greg Stein <gstein@lyra.org>
>
>    As Geoff stated: you can use version-controlled resources,
> labels, or
>    baseline selectors to create human-readable URLs.
>
>    The version resource URL is (IMO) typically private and
> does not need to be
>    readable. Primarily, the URL needs to be *stable* and *persistent*.
>
> This thread brings to mind a related topic, which has an even more
> negative impact on interoperability then weakening the MUST to a
> SHOULD, namely "mutable versions".  A mutable version is actually even
> worse than a server re-using a version URL, because it provides a way
> for a *client* to break versioning semantics.
>
> But I believe the thread on "re-use of version URL's" points out
> an interoperable solution to the "mutable version" issue.  In
> particular,
> clients that want mutable versions want to use the same
> "name" to apply
> to one state at one time, and another state at another time.  But
> we already have a mechanism for doing this in the protocol, namely
> labels.  In particular, if a mutable versioning client uses *labels*
> to identify versions of interest, then we get interoperability.
> When a mutable versioning client wants to "change" the state of a
> version, they just create a new version and apply that label to it,
> and that *label* then acts as a "mutable version identifier".
>
> The only thing we are currently missing to make this work, is
> to provide
> a way for a mutable versioning client to tell a mutable versioning
> server that it wants to create a new version as a replacement of
> an existing version.  But all we need for this is a "label" parameter
> to the checkin command, which tells the server which labeled version
> this is supposed to "replace" (effectively combining a "checkin"
> with a "move label" operation).
>
> So I propose that we replace the current "mutable version" option
> with the ability to specify a label in a CHECKIN request.  This gives
> us one fewer option as well as significantly improved
> interoperability,
> while still providing the semantics required by a "mutable versioning"
> client and server.
>
> Any objections?
>
> Cheers,
> Geoff

Received on Friday, 5 January 2001 12:50:00 UTC